Which products are affected by NSA's ability to crack pseudo-random-number generator Dual_EC_DRBG?

(*cough* alleged ability *cough*)

TL;DR: There is widespread use of BSAFE, and widespread availability of (though not necessarily use of) Dual_EC_DRBG. Though there is a lack of definitive vendor statements at this time, there is an unsubstantiated claim that SecureID is not at risk from this, and other than a single McAfee product, nothing seems immediately at risk.

The crypto.se question Who uses Dual_EC_DRBG? doesn't identify many actual products, primarily just the RSA BSAFE developer library.

The actual RSA advice/statement (presumably limited release) appears at the end of this article. In that Wired claim to have a source who states no SecureID (hardware or software) uses the affected PRNG. Since it could be quite expensive and embarrassing if it was the case, you may choose to disbelieve this ;-)

Since we know the RSA BSAFE library uses Dual_EC_DRBG (inexplicably, since there has been suspicion hanging over this PRNG since 2007) by default, I would guess that this would be the main vector, and your question should be answered by D.W.'s similar crypto.se question Who uses the RSA BSAFE library?, which is unanswered at this time ...

This rather old (1998) and slightly ironic RSA Bulletin Preliminary Analysis of the BSAFE 3.x Pseudorandom Number Generators (PDF) opens with:

  An enormous number of commercial applications (over 350 million copies) rely on the BSAFE and JSAFE toolkits from RSA Data Security to generate cryptographically strong pseudorandom numbers

hinting at the potential scale 15 years ago, and prior to the freely available version (and also prior to the affected algorithm).

Given the lack of a CVE, the NIST DRBG Validation List (Google cached copy) is probably a good start (though not necessarily a comprehensive list). Vendors with validated Dual_EC_DRBG implementations include Juniper, Cisco, RIM, Symantec, Riverbed, McAfee, SafeNet, Microsoft and OpenSSL. Only terse information about products is given, if any.

See this article for some (unsubstantiated) vendor statements:
 http://www.crn.com/news/security/240161911/cisco-mcafee-other-firms-addressing-nsa-linked-encryption-algorithm.htm

Regarding OpenSSL, it's not the default PRNG, and soon won't be supported at all.

McAfee Firewall Enterprise Control Center (uses BSAFE) only uses Dual_EC_DRBG in FIPS deployments

Several versions of MS-Windows support Dual_EC_DRBG, somewhat ironically (PDF) but it's not a default, though as Schneier says:

  “A Trojan is really, really big. You can’t say that was a mistake. It’s a massive piece of code collecting keystrokes,” he said. “But changing a bit-one to a bit-two [in the registry to change the default random number generator on the machine] is probably going to be undetected. It is a low conspiracy, highly deniable way of getting a backdoor. So there’s a benefit to getting it into the library and into the product.”

As for the use of BSAFE, I can easily find (hint: use your favourite search engine to search for the terms "This product includes" "RSA BSAFE") implementations, oddly skewed towards imaging and gaming devices:

surprisingly many printer/copier/fax devices use BSAFE, though for unknown purposes. Including Ricoh, Minolta, Océ/Canon, Brother, Fuji/Xerox, Epson ...
Your Playstation (PDF), PSP, or your Nintendo DS wifi (PDF)
Software from Adobe, Hitachi, Oracle and HP
Some Nokia phones(PDF)


Hack: anymonous URL on my Joomla Website[Resolve]

JRoute is the module tasked with dealing with internal urls. The evil code is hooking there to make such urls show their spam page.

You could see what they changed by comparing the files with the official ones from Joomla. In the end, you should replace the compromised Joomla php files with the original ones.


How can I secure my server to ensure pre-login calls are originating from my app?

In general, you can't. If you want to execute code on a user's machine, nothing whatsoever stops that user from manually doing the very same stuff themselves. You cannot effectively keep something secret from a motivated user and simultaneously run it on their computer; any secret in the app's code is accessible to the user. The solution is that you can't trust user-supplied input; if it's critical people not be able to submit feedback forms under fake names, for instance, you should have a user-specific secret that isn't built into the app (so that a user doesn't know other users' secrets, e.g. a user token) and use that to ensure people are who they say they are.


What does a switch do against a packet sniffing attack?

By their function, a switch will only forward packets to the port where the destination computer (identified by it's MAC address) is. For this reason, they are said to mitigate sniffing attack.

However, switches are not security devices but network devices. In order to know where a specific computer is, they have to learn where they are. For this, they read the MAC address of computer in the different packets that goes through them. When possible they will assign MAC to a specific port and continue to forward traffic related to this MAC to this specific port only. Due to the protocol, you can take advantage of this by performing ARP poisoning, confusing the switch which ultimately will continue to operate as a simple hub, forwarding all traffic to all ports. With this attack, one can still perform sniffing.


How can we represent SSL and Firewall in OSI Model?

A firewall may work at different layers of the OSI model, going from layer 3 to layer 7 (depending on your firewall). Representing it in a diagram will require to set rules for each layer. I would represent the firewall and include a list of all enforced rules on each layer. Some examples could be:

Layer 3: IP filtering
Layer 4: port filtering (TCP/UDP)
Layer 5: session layer firewall (state of the connection)
Layer 6 and 7: application layer firewalls (more inteliggent, can perform deep packet inspection, close to IDS/IPS)

For the "SSL" I presume you mean an SSL offloader. SSL/TLS takes place at the presentation layer or layer 6 of the OSI model.


Understanding NTLM Authentication Step by Step

Here is the wording from official source:

  The following steps present an outline of NTLM noninteractive
  authentication. The first step provides the user's NTLM credentials
  and occurs only as part of the interactive authentication (logon)
  process.

  (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The
  client computes a cryptographic hash of the password and discards the
  actual password.
  The client sends the user name to the server (in plaintext).
  The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
  The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the
  response.
  The server sends the following three items to the domain controller:

  User name
  Challenge sent to the client
  Response received from the client

  The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It
  uses this password hash to encrypt the challenge.
  The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If
  they are identical, authentication is successful.

So the challenge is a server generated message that is encrypted with the hash of the account password by the client and by the DC and compared on DC.

Encryption methods are variable between versions of NTLM and different server settings.

Here's a bit from Wikipedia:

  Both LMv2 and NTv2 hash the client and server challenge with the NT
  hash of the user's password and other identifying information. The
  exact formula is to begin with the NT Hash, which is stored in the SAM
  or AD, and continue to hash in, using HMAC-MD5, the username and
  domain name.


Are virtual keyboards not necessary anymore to protect against keyloggers?

Virtual keyboards were an easy-to-implement solution to malware that recorded keystrokes from the keyboard and hardware keyloggers.

But the keylogger software developers quickly adjusted to this new technique (sometimes by simply taking a screenshot focused around where the mouse clicks).

In the end, it is not clear that a virtual keyboard provided any broad benefit. It would certainly defeat a hardware keylogger installed on your keyboard, but that's not the likely threat.

Given that keylogging software expects to also capture virtual keyboards, there is little benefit to maintaining this technology in the broad, likely scenario.

Tests have been done on the effectiveness of virtual keyboards:

https://www.raymond.cc/blog/how-to-beat-keyloggers-to-protect-your-identity/


Stopping, editing, then sending packets in Windows 10

There a few differents way to do this:

On windows there are the tool windiver who can modify packets on the fly
You can also use a virtual machine with Linux to use several tools like netsed, hexinject, proxyshark, mallory,...
On the Linux VM, you can use MITM framework which have many features like intercept packets on the fly and edit it, sometimes it can inject shellcode in binary,... One popular framework is MITMf


This is a malicious request, but it's not trying to exploit a vulnerability. It's trying to generate a 404 page, in order to determine what kind of web server or CMS you're running, by identifying tokens in the page source. Error pages often specify their CMS name and version, or the web server name and version, so it's an easy target for recon.

Best advice I can give you is to keep everything patched, and make sure your firewall rules are properly configured. Primary targets are likely to be your CMS and web server, but your OS is important to patch too.

If you've got a few IPs that constantly do it, and you're certain they're not valid customers, feel free to block them for a few weeks to see if they remain persistent.


Self-signed certificates usage for code signing purposes

A Certificate Authority is just one component of the Public Key Infrastructure.   The PKI is "a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates."  A CA alone isn't very helpful...

You can use self-singed certificates securely by using Certificate Pinning.  This is where you know what certificate to expect,  so you don't need a PKI to verify its authenticity.


malicious file on my websites, can't delete it

What about uploading yourself some shell code which would delete the file?

Something like deleteThaFile.asp:

<%
     Set oFileSys = Server.CreateObject("Scripting.FileSystemObject")
     Call oFileSys.DeleteFile("nul.doc.asp", True)
%>

Would that help?

You could also use the FileSystemObject to get some more information on the file (and other files) to better understand why it cant be deleted.

May be you could also deploy there some more generic ASP shell like file-manager, to see more what can be done about the file.


Like bluetooth and 802.11, I think we will see eavesdropping used in many attacks.  I suspect that some variant of the classic man-in-the-middle attack will crop up too, despite being mitigated as much as possible in the design of the specifications. Although I don't have practical experience or familiarity with these attacks, I can point you to a few articles that you may want to check out:
Slides: "Practical Experiences with NFC Security
on mobile Phones"
Security in
Near Field Communication
Security Risks of Near Field Communication
A presentation on NFC security at BlackHat USA 2012
Summary of blackhat presentation


What risks do I have to consider when encrypting server side as opposed to client-side?

You say you want to use server-side encryption to limit exposure to client-side malware.  That makes no sense.  If there is malware or spyware on the client, then you are hosed either way.  Encrypting on the server doesn't help, since the data still exists in cleartext on the client, and so the client-side malware/spyware can capture the cleartext data.

I think you need to revisit your requirements and your approach.  If you are worried about client-side malware, I can see only two options: (1) ensure that sensitive data never reaches the client in cleartext, or (2) implement defenses to reduce the likelihood of malware on the client side.  Encrypting on the server side doesn't really help.

Sending the data from the client to the server and then encrypting on the server has all the security risks of client-side encryption, plus some additional risks:

If the server is compromised, or if any of the accounts of your employees are compromised, then the attacker gets access to the data.  (Twitter got hosed by the latter.  Many companies have gotten hosed by the former.)
Because you technically have the ability to decrypt the data, it now means you can be subject to subpoenas, warrants, or demands from law enforcement to decrypt the data if they want/need access.  If you are a small operation, this might not be a big deal, but at a big operation, this might start to create some compliance costs for you.
If the attacker can mount a man-in-the-middle attack (e.g., attacking a user who is connecting over open wifi), and if the user clients through SSL cert warnings, then the attacker can gain access to the sensitive data.

One advantage of server-side encryption is that it enables you to do key management on the server side, reducing the burden on users.  For instance, if users lose or forget their keys, you can recover it for them.

Another possible advantage of server-side encryption is that the time window when the data exists on the client side in cleartext might be reduced, which might reduce the exposure to data breaches if, e.g., the client machine is stolen or lost.  However this advantage may be fairly modest in practice, and there may be better solutions to this issue (e.g., full-disk encryption).


What measures exist to protect against an attacker "forcing employees to comply"

Some common terms for this is "rubber hose cryptography" or sometimes "monkey wrench cryptography". I have also heard it being refered to as "the one side channel to rule them all", but that is hardly an established name.

What this boils down to is the realisation that in the end all security relies on physical security. If the place where you store the key is not secure, the data protected by the key is not secure. If the place where you store your key is your memory (or your back pocket), what we are talking about here is your physical security.

There is no silver bullet for this one. A clever trick like hidden volumes is not useless, but I can imagine that a violent, determined, and competent attacker would make you talk about them.

You can split the key or store the parts on different locations. Or you can leverage an existing institution by putting the key in a safe deposit (that requires you to show ID) at a bank. Both of these are very unpractical if you need the key for daily use, and both can of course be broken. In fact, the last one might even just escalate the situation when the attacker is forced to take more drastic actions to compulse you to get the key from the bank.

Others solutions include setting up a dead man's switch (where the data is automatically deleted unless you check in each day) or having a fake key that when used deletes the data. These could prevent the attacker from getting to the data, but obviously at the cost of the data being deleted.

And would you really like to deal with the guy with the monkey wrench after he finds out you duped him? If you are worried about a violent attacker, you need to have a hard think about wheater the integrity of your data is really more important to you than your knee caps or your life. In a lot of cases, the best solution is to give up and give the guy with the monkey wrench what he wants. After that, you can call the police. Unless the attacker is the police, of course...

So why doesn't the bad guys always attack with a rubber hose instead of with Metasploit? Using violence is expensive:

The victim will know that you attacked, and stole the data.
You need physical proximity to the victim, and the attack can not be automated.
A lot of people think you can still go to heaven even if you abuse SQLi vulnerabilities, but waterboarding will land you in hell.
It is risky. What if the victim fights back? What if you get caught? I have never heard of anyone getting shot while doing packet injection.
The police is way more likely to try to track you down if you commit violent crimes. And they are way more likely to succeed - covering your traces in the real world is hard. You can not hide behind a proxy server in Nigeria.

So unless your day job is being James Bond, perhaps you should not worry to much.


As per this answer CSR with only public key with openssl

The CSR only contains your public key, not your private key, so your private key has not been compromised.

The .csr files will both still be valid no matter what.

When you send the CSR to a Certificate Authority, they will produce a signed x509 Certificate. Any computer that trusts the CA will then consider that certificate valid.

If the CA is the third party that is compromised, then it is likely that the signed certificate is useless as nobody will trust it.

If a man-in-the-middle captures the csr it does them little good, as the only key available is your public key.


OSSEC - Can i centralize what file to check with centralized agent config?

It seems interesting you ran into the same case I did.

You can follow these steps:

Create a new config file on the server/manager: vim /var/ossec/etc/shared/agent.conf
Place configuration in that file you want to be merged on clients/agents.
Save it (Press : then wq and enter).
Get the current hash of the config via md5sum /var/ossec/etc/shared/agent.conf
Inspect the agent 001's config via /var/ossec/bin/agent_control -i 001
When the agent received the configuration, the “Client Version” field will have the md5sum of the agent.conf file.

You will however find that it will not work on Windows agents. Linux agents might be a different story. If you are interested, you can see the pain I went through:

https://serverfault.com/questions/877991/ossec-windows-agent-fails-to-sync-configuration


does openssh support authentication using public key fingerprints?

No. The authorized_keys file contains strictly only the public key, as described in the manual page for sshd:

AUTHORIZED_KEYS FILE FORMAT
Each line of the file contains one key (empty lines and lines starting with a ‘#’ are ignored as comments). [...] Protocol 2 public key consist of: options, keytype, base64-encoded key, comment.

Accepting the key only based on the fingerprint can work only if you will send the public key before you request authentication (the server needs to verify your authentication by decrypting the challenge using the public key). Since MD5 is already considered as cryptographically broken it might be a security issue.


ADFS 3.0 OAuth2.0 against client applications

Yes. Using the authorization code flow client side will have almost the same effect as using the implicit grant flow.

There will be a few extra requests but the end result will be the same with some caveats:

The implicit flow spec says the token must be in the URL's fragment so it doesn't leave the user-agent. You won't have this with the code flow
You should not enable refresh_tokens for the client.

Also the same security concerns as for the implicit flow apply. See RFC6748 section 10.16:

  Authenticating resource owners to clients is out of scope for this
  specification. Any specification that uses the authorization process
  as a form of delegated end-user authentication to the client (e.g.,
  third-party sign-in service) MUST NOT use the implicit flow without
  additional security mechanisms that would enable the client to
  determine if the access token was issued for its use (e.g., audience-
  restricting the access token).

And on the client credentials front you were already covered:

  Native applications that use the authorization code grant type SHOULD
  do so without using client credentials, due to the native
  application's inability to keep client credentials confidential.

Footnote: Be sure to read RFC6819 section 4.4.2  to avoid other common implicit flow pitfalls.


Why can't the police/government shut down black market websites?

There are a few issues:

Resources: You have to have the technical skills to track down these resources, you need to collect evidence, deal with legal issues (judge, subpoenas, chain of evidence), you may have to actual get in and do some trades to make evidence, this may require physical receipt of items (if its all just talk - is it even real? Is it all hearsay?  You need to have time, available specialists, and it has to be prioritized with other cases, some of which have a greater chance of success.

Jurisdiction: Even if you manage to track down international criminals, if they are operating across borders there may be jurisdiction issues, you may need to collaborate with various departments (which could be difficult logistically), there may be language issues, etc. International law may also make this difficult - extradition, etc. Is this even a priority in the country where it's going on?

Let's take the simple case of a very amateurish website hosted on some cheap hosting provider. This might be easy to shutdown because its in a clearly identifiable place, and the hosting provider can just turn it off if they want, which they probably would just do if a government asked - your small monthly fee isn't worth having the government hassle them.

However, let's say its hosted in a distributed manner, mirrored all over the world. There is lots of encryption, they use weird code words, a lot of the actual criminal transactions actual take place over email, icq, or something else. They use encryption, they move IPs, they host the servers in countries where the government or the ISPs don't care. It's going to be pretty hard to get access just by stumbling upon such a site. These things are often communities suspicious of outsiders (and suspicious of even their friends). So it may be very hard to prove it's worth turning off and in reality, there is no magic single-point of failure you can just turn off. Even if you took down a website, they could make another one, or use fancy peer-to-peer systems to distribute and encrypt what they are doing.


How to test post login pages for sql injection using sqlmap

I believe you would need to submit the query with the parameter id

This might help you:
sqlmap -u http://localhost/dvwa/vulnerabilities/sqli/?id=2&Submit=Submit --cookie="security=low; PHPSESSID=loif1hgpc539lith3rvbe1coh1" -p id --dbs


Is face recognition a good security feature?

No, not really. At least not as primary form of authentication. Biometrics in general are not good for authentication, because:

You leave them all over the place, and there is no way to avoid that.
They cannot be changed in case of a breach.
You need to add a high error tolerance as to not cause usability problems. These tolerances lead to false positives, even without attacks, and make attacks possible.

In practice, when implementing the algorithms, they usually have to
balance between [false acceptance rate] and [false rejection rate].
This makes the efficiency of face recognition the lowest of all
regarding the table. Its security is also lower than other biometric
recognition system, especially compared to fingerprint scan.
— Your
face is NOT your password, Face Authentication ByPassing  Lenovo –
Asus – Toshiba
(2009)

I couldn't find a live demonstration for that paper, but here is one from a 31C3 talk about biometrics, which uses a simple picture, and can bypass required blinking. Here is an article from a person using a video to bypass a blinking requirement.
Here is a more recent paper using more modern approaches:

In this paper, we introduce a novel approach to bypass modern face
authentication systems. More specifically, by leveraging a handful of
pictures of the target user taken from social media, we show how to
create realistic, textured, 3D facial models that undermine the
security of widely used face authentication solutions.
[...]
In our opinion, it is highly unlikely that robust facial authentication
systems will be able to operate using solely web/mobile camera
input.  Given the widespread nature of high-resolution personal online
photos, today’s adversaries have a goldmine of information at their
disposal for synthetically creating fake face data. Moreover, even if
a system is able to robustly de- tect a certain type of attack - be it
using a paper printout, a 3D-printed mask, or our proposed method -
generalizing to all possible attacks will increase the possibility
of false rejections and therefore limit the overall usability of the
system.
— Virtual U: Defeating Face Liveness Detection by  Building
Virtual Models from Your Public Photos (2016)


From this link Redhat suggests:

Red Hat does provide a high level of security in the operating
system and packages that they distribute. As security issues are
discovered in various applications (and presumably in packages),
Red Hat provides updated packages in a way which keeps potential
risk to a minimum;
Red Hat Enterprise Linux 3 and higher employs ExecShield to eliminate
the possibility of Buffer-Overflows (so greatly reducing the possibility
of many exploits);
Redhat's own network, systems and packages are kept updated with all
patches and security updates;
Redhat's own systems have Security-enhanced Linux (SELinux) enabled; and
A friend I know who is a Kernel developer for Redhat tells me realtime
filesystem scanning is also used on Redhat's own systems in addition to
the above, as well as 3rd party Linux antivirus.

So, to answer: Although there is no such thing as guaranteed perfect security, Redhat (meaning the owners of the rhel-7-server-rpms (and related repo)) appears to be doing due-diligence (risk management) sufficient to give you a reasonable degree of confidence.  Your confidence isn't misplaced.

That said, I'm talking about the rhel-7-server-rpms repo, and not some non-Redhat repo.


There used to be a "vulnerability" where the image could send a HTTP 401 Unauthenticated response, which would trigger a login screen for the user. If you set this as forum avatar, it would spawn a login popup for anyone visiting a page where your avatar appears. Lots of people will then attempt to log in with some username and password combination, probably the one for their forum account.

A friend of mine found this a few years ago, but nowadays it doesn't seem to work anymore. At least I couldn't easily reproduce it a few months back. Edit: I was wrong, this attack is still possible! /edit

As for XSS attacks this way, you're safe. The browser will, or should, always interpret this as an image no matter what it contains or what headers it sends. You can customize the image based on the request (serving a small image to the forum software prechecking the image so that it doesn't downscale it, then large for everyone else). Or feed the browser lots of gif-data until memory runs out or something. But there are no real big vulnerabilities here that allow Remote Code Execution as far as I know.

What you are only moderately safe for are CSRF-attacks. The image can issue a HTTP 302 Moved Temporarily response and link to a new location. For example it could link to, I don't remember the specific URL, something like https://accounts.google.com/logout and log you out of google (this worked a few months ago). Or, slightly more maliciously: http://example.com/guestbook.php?action=post&message=spam-url.example.com.

Only GET requests can be done this way as far as I know. Or if the image was originally being loaded as POST request, I suppose it could also redirect the POST, but not change the POST-data. So that's pretty safe.

Last but not least, if the attacker controls URLs of for example forum avatars (such as in SMF forums), it's possible to obtain information from visitors such as their IP address. I wrote a tool a while ago that used the action=who page of SMF to link IP addresses to usernames. When I started displaying that to users (show "Hello $username with IP: $IP" in the image) all hell broke loose. "How could you possibly know that?!" They were mostly early- to mid-teen techies so they knew what an IP address was, but didn't know that I couldn't hack them with it. It is however considered to be personally identifiable information, at least in the Netherlands, so the admins weren't quite happy about this practice. If you don't display it though, nobody will ever know.

Note: If this post seems hastily written, it is. I'm barely awake too. Perhaps I'll clean it up tomorrow if it's too much storytelling and not naming enough concrete facts and vulnerabilities. Hope this helped anyway!


How can my country's legal/telecoms environment protect against cold-callers conning a remote-access session to the victim's computer?

In the US, a telephone customer can dial *57 after the call to get a "Customer Originated Trace" - which theoretically "Provides the recipient of an abusive call the ability to request an auto-trace of the last call received".  Not sure what the definition of abusive there is, or the latest reality of how well it works.


What are the security implications of capabilities in Kubernetes pods?

For this I think it's quite probably that a rogue process running with that capability would be able to affect the underlying host, if only indirectly.

From this man page we can see that CAP_NET_ADMIN provides quite a few privileges, including interface configuration

       CAP_NET_ADMIN
              Perform various network-related operations:
              * interface configuration;
              * administration of IP firewall, masquerading, and accounting;
              * modify routing tables;
              * bind to any address for transparent proxying;
              * set type-of-service (TOS)
              * clear driver statistics;
              * set promiscuous mode;
              * enabling multicasting;
              * use setsockopt(2) to set the following socket options:
                SO_DEBUG, SO_MARK, SO_PRIORITY (for a priority outside the
                range 0 to 6), SO_RCVBUFFORCE, and SO_SNDBUFFORCE.

These permissions are restricted to the namespace of the process, but allowing an interface to go into promiscuous mode could allow for traffic to be sniffed from other interfaces on the host, depending likely on the CNI configuration.  Also as noted in this white paper there have historically being some breakouts and privescs related to NET_ADMIN.


AFAIR they have an auto-response message, have you received it? They say that it may take some time to respond to reports, but they typically do respond.

If you haven't received their auto-response, there are several options:
- you've got the wrong e-mail (I doubt it though)
- you've received the message, but it was filtered


Classification of attacks in network specially in Snort IDS

All snort rules are categorised. Please see here - http://blog.snort.org/2012/03/rule-category-reorganization.html.


Should I present forged documents in a Penetration Test/Red team engagement?

It depends on the scope of the engagement.

If the customer wants you to focus on one specific task (e.g. bypassing locks, social engineering, etc.), then that's all you're authorized to do and all you are legally allowed to do.

If the customer wants you to use "anything that's legal", in order to best simulate a real attacker, them you can indeed present a forged permission to attack, possibly even with instructions added that you should be left alone during the engagement.

Why would you do that? In order to check if security personnel actually verifies of a Permission to Attack is valid or not. Otherwise an attacker could present a forged Permission to Attack and use this to gain entry to the company?

What about law enforcement?

Never show law enforcement a forged document or lie to them about who you are or what you are doing. You are testing the company, not the law enforcement.

Or to put it in simple terms: When you talk to the police, you're no longer a pentester.


Possibility of using CA as an attack point by governmental organizations under their pressure

Pre-Snowden, I would have dismissed this question as being in the "tinfoil hat" category.

Unfortunately, the NSA's pervasive misconduct (not to mention that of its "Five Eyes" junior partners, e.g. GCHQ, CSIS, and whatever the Australian and N.Z spook agencies are calling themselves these days), does indeed raise a troubling question.

The specific possibilities are numerous, but let's consider only two of them :

(1.) NSA could -- by asserting the USA PATRIOT Act and various other similar laws -- simply demand that a CA remit its root private encryption and signing keys. This would of course allow 100% effective masquerading by the NSA, with respect to any downstream certificate in the chain (since, the subordinate certs would appear to have been signed by the root CA's legitimate private key).

(2.) NSA could, also, install some kind of SSL interception (MiTM) box (which they are already well-known to possess) in front of the CA's root network architecture. This would allow some of the same functions as (1.) (but would be less flexible).

"Certificate pinning" can mitigate some of the risks here, but of course it would be of little use in the case of scenario (1.).

Unfortunately, what this really all goes to show is the truth of the familiar security aphorism, "if an attacker (in this case "No Such Agency") can get physical access to your box or network, it doesn't matter what security measures you may undertake; you'll be 'pwned' one way or another".

In the long run, I think the only halfway-valid mitigating step would be to only use Certificate Authorities that are :

(3.) Located outside the physical jurisdiction of the "Five Eyes" countries (as well as outside other countries whose political system cannot be trusted to respect privacy -- Russia, China, Iran, Germany, Israel, India, Pakistan, etc. spring to mind); and,

(4.) Are located in a country (or other setting) with a sufficiently sophisticated IT staffing environment so as to make them as immune as possible to subversion attempts on the part of state intelligence agencies working for the countries denominated in (3.) above; and

(5.) Are located in a network environment that is reasonably resistant to subversion on the part of the same intelligence agencies.

The problem here is, apart from the fact that the Venn diagram arising from the intersection of (3.) to (5.) above is likely to result in a very limited number of physical jurisdictions (Switzerland, maybe? I'd have said "Sweden", except for the Pirate Bay and Assange fiascoes), any CA located in this kind of setting would be a tempting target for "No Such Agency" and its partners in destroying trust on the Internet.

A CA is, by its very nature, a single point of failure in this respect, and it is only rational for a very well-resourced, unscrupulous entity like the NSA, to expend "whatever it takes" (keep in mind that the NSA's budget is already several multiples of the entire state budgets of many smaller nations), in order to be able to subvert all supposedly "secured" traffic that depends on the integrity of the CA's private keys.

So there you have it. Not particularly good news, but IMO that's an honest description of the situation as it now exists. Send all cards of thanks and appreciation to Michael Hayden, Keith Alexander, James Clapper, George Bush and Barack Obama (with their junior U.K. and other friends, along for the ride).


Public AP: How to reduce vulnerability window between Captive Portal and starting VPN?

I suppose another approach is "punt on public AP whenever possible, and tether to a VPN connection over your phone instead". Chews up data though.

You have basically two strategies for your risk (surfing on a public AP).

Elimination: Not using it
Mitigation: Taking precautions to reduce the probability and impact of having information disclosed.

  How much should I worry about the window of time where I am in the captive portal (the agreement screen) and have not yet started my VPN?

VPN will just help you by encrypting your data traffic, which I understood as your major concern when surfing on a public AP. You will be unable to surf anyway until you pass the "captive portal", so I don't see a lot of risk here from a browsing perspective, as long as the only tab you have opened is "agreement screen".

However, once you boot your Mac, some of your applications are very excited awaiting for a network connection. As soon as you connect to the public AP they will try to connect to the Internet (which will fail since they will be probably faster than you opening the "captive portal". Depending on how they were built there is  a risk of revealing information. e.g.:

Password in an url [Caught by a sniffer]
DNS spoofing [An application pretending to be the one your application is expecting]
Browser tabs previously opened or installed addons [Although here you could be protected by a time-out])

  Other considerations

You are heavily focused on the disclosure of data in transit, however there are other risks when connecting to an unknown AP.

However keep in mind (one example of many others) that someone could by scanning your ports in order to attack open ones which have vulnerable applications listening to it. VPN won't help you here.


What attacks are made possible by public release of my web history?

Your question might be more undefined than you realise. Any kind of data can be passed using URL parameters. Usernames, passwords, authentication tokens, settings, form data, or anything the web developer chooses. It's not always good practice to use URL parameters to for this, but it is always possible.

And it's entirely up to each individual web developer on each individual page (not just site) as to what might be exposed and when. So you might not be able to predict what might be exposed.

So, to answer your question, in the worst case, you could experience a complete and utter disclosure of any amount of personal data including credentials.

By request, I did a search for the practice of "passwords in URL parameters" and restricted results to this year. Here's one of the top hits:

https://answers.splunk.com/answers/622600/how-to-pass-username-and-password-as-a-parameter-v.html

That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this.

Here is OWASP's official page on this vulnerability:

  The parameter values for 'user', 'authz_token', and 'expire' will be
  exposed in the following locations when using HTTP or HTTPS:

  Referer
  Header  Web Logs  Shared Systems  Browser History  Browser Cache
  Shoulder Surfing


From RFC 3647: Internet X.509 Public Key Infrastructure -- Certificate Policy and Certification Practices Framework:

  4.4.6.  Certificate Renewal

  This subcomponent is used to describe the following elements
  related    to certificate renewal.  Certificate renewal means the
  issuance of a    new certificate to the subscriber without changing
  the subscriber or    other participant's public key or any other
  information in the    certificate:

  Circumstances under which certificate renewal takes place, such
  as
    where the certificate life has expired, but the policy permits the
    same key pair to be reused;

Which contradicts itself in that it initially states that during renewal you cannot change the public key or any other information in the certificate, but then goes on to say that a renewal can take place where the certificate life has expired.

and...

  4.4.7.  Certificate Re-key

  This subcomponent is used to describe the following elements
  related    to a subscriber or other participant generating a new key
  pair and    applying for the issuance of a new certificate that
  certifies the new    public key:

  Circumstances under which certificate re-key can or must take
    place, such as after a certificate is revoked for reasons of key
    compromise or after a certificate has expired and the usage period
    of the key pair has also expired;


VPN doesn't function properly on google websites

I strongly suspect that the VPN is working but you're leaking information in another way. Some things to try are:

Turn off location services on your computer
Use incognito mode
Disable all browser extensions in incognito mode (I think this isn't the default in Firefox)
Make sure you're not leaking data via WebRTC
Don't login to Google (or any other sites)
Flush your DNS cache in case you are pointing to a region-specific IP address of Google

If this still doesn't work, visit browser fingerprinting sites such as Panopticlick to see if they provide you with any hints.

Update: Perhaps Google is not actually detecting your location, but is instead getting an Accept-Language header from your browser. See what happens if you do the above and set your browser's language preference to English.


Did scammers take control of a subdomain to host phishing site?

By the looks of things, assuming that the link you've provided is correct, they didn't.

By using the Nationwide website (as accessed by typing in the domain name manually, to preclude any similar character attacks), and using the search function (http://www.nationwide.co.uk/search?term=payment%20assistance), that subdomain showed up in the list of results.

The link for the second result is https://paymentassistance.nationwide.co.uk/

The general approach when it comes to things like this is to do this - search and check that the address you are using is correct (if you have paperwork from the organisation with the address on, even better). Type it in, rather than following the link, just in case. If they have a search engine, look for whatever is suspicious, and if it turns up, chances are, it's legitimate. You can also try phoning them, or popping into your local branch, in the case of a bank, to verify this.

Additional informationI contacted Nationwide via their online banking contact section, and got the following response:

  Completely understand how this could cause you some concern.

  Don't worry, this is a genuine Nationwide website.  This is from our Credit Card Services as they're most likely wanting to double check a payment with you.  It's completely safe for you to go ahead and complete this.

  If you're a little uneasy about completing this online, please can I ask that you give our Credit Card Services a call directly.

If you are still concerned, I suggest contacting then in this way!


AES is a subset of Rijndael (FIPS-197). It's still being considered secure, if you continue reading to the bottom of the article:

  Even if the largest botnet ever discovered – the
  30-million-computer-strong BredoLab botnet – was given the task of
  attacking an AES-256 implementation, the sheer number of possible
  combinations would make the task virtually impossible.

The attack you suggested is called a biclique attack and is slightly faster than it would take to bruteforce an AES key. Considering that would still be a a few trillion years it's not really feasable.

Also this is the  official press release from the Katholieke Universiteit Leuven about the code being broken. (This is the university where both AES and the attack against it were made)


Random mouse input vs random keyboard input vs CryptoAPI

Boiling down RNG (random number generators) discussions:  It all depends on how your system and/or software you're using wants to use the random number entropy pool.

Most systems rely on the OS kernel to maintain a pool with sufficient entropy to provide all RNG operations.  If hardware is available, this will use disk rpm, interrupt operations, even thermal changes in CPU (Haswell).  In the case of your software package that wants mouse movements for key generation, it's most likely seeding it's own entropy pool because it doesn't necessarily trust the OS.

There's a lot of discussion around limitations of RNG in virtualized environments (though most have been quelled with good research), but in the case of software manually asking for "movements", the movement provided by a human using a keyboard or mouse will generate enough random data (not just the movement but the I/O variables) to compensate for insufficiencies in the OS entropy pool.  What the software is showing is not the actual entropy and unless it was written by a 4 year old, mouse movement will generate plenty of I/O entropy to satisfy most pseudorandom number generators falling just short of NIST/FIPS compliance.

This is where TrueCrypt failed because while they allowed hardware to manage entropy management, they capped their prime number ranges, allowing easy guessing of numbers used for keygen (from what I read).

Makes sense?


Why don't companies just tie the password to the user name?

One problem with passwords is that if they can be broken as follows: pick a random password; hash it; compare that hash to other known hashes. This way, you have broken the code.

It was long ago that type of password mechanisms were used. Today we use random salt per password, and additionally, a server-based pepper. Then the user's password is hashed using a password hashing algorithm that is designed computationally intensive and memory-hard; like Scrypt and PBKDF2. The aim is to cripple the attacker by eliminating the massive parallelization of the GPU/ASIC and reducing the time to search like 100K iterations. No more parallelization, no more fast search, and no more Rainbow tables. Today's modern standard is the Argon2 that is the winner of the 2015 password hashing competition.

However, isn't this easily fixed by tying the password to the user name?

That doesn't differ since the method is assumed to be known to the attacker; a real attacker also assumed the target's personal information, too. That is why you should not include anything that is personal in your passwords.
Besides you need to store this random information, too, that will increase the complexity of the self-written code.
The real problem with the passwords is the user's side or call human side. One can be taught to use dicewire based passwords that are easy to remember and have strong strength. The XKCD 936 is the famous cartoon for this.
Besides, a strong piece of advice is using password managers like open-sourced KeePass, which can store all of your passwords securely, even you don't need to generate them. Even Firefox has a password manager mechanism.


If SSL encrypts urls, then how are https messages routed?

The DNS server does not look at the URL; the DNS server does not know what a URL could be.

The client browser extracts the intended server name from the URL. In a URL like https://www.example.com/foobar.html, the server name is the part after the https:// but before the next /; i.e., www.example.com in this example. The server name is what is sent to the DNS.

The DNS responds with the IP address for that server. The client then talks with that server, they do their SSL magic, and once the tunnel has been established (and only then), the client sends the URL (specifically, the part after the server name, in my example /foobar.html) to the server. And that one goes in the tunnel, hence encrypted.

This answer is a walk through the SSL protocol.


What are the risk of providing identity in my application, rather than using a provider?

But, the biggest issue stems from not leaving the identity up to the experts that have studied the numerous standards and security policies. Sure, you could learn all of it yourself and implement it securely, but it will be time and resource consuming. That's just the tradeoff you have to make (as it is with many SaaS solutions).
If you're storing the identities in your application database, you open the door to a hacked application leading to hacked identities. Versus if it were separate, you could have better encapsulation there. Bad practices in storing passwords or passing them over unencrypted protocols could lead to stolen identities.
*I'm biased as I work for an Identity Provider, but I've tried to be completely open and honest here.


Is a session token enough for critical applications

If you use cookies to store session ID's just make sure it is set in a cookie with the Secure and HttpOnly attribute. Restrict the domain and path attributes as much as possible. Make sure no untrusted web application is hosted on a related domain who could launch a session fixation attack. Set a reasonable expiration time for the session. Serve all your pages over HTTPS since mixed content might leak your session ID. Try to limit the externally loaded JavaScript libraries to minimize the attack surface.
Some application servers like Tomcat allow you to use SSL session ID's instead of session ID's stored in cookies. These SSL session ID's are better protected but you should be able to share the SSL session over multiple servers in your case.
A lot more tips can be found here: Session Management Cheat Sheet
EDIT:
They are no working on binding tokens like session ID's to a client via public-private key and signing. Read the RFC here. It will take some time before it will be adopted by the major browser vendors but as far as binding a session ID to a client goes, this seems to solve all the issues. Of course there is some key generation and signing overhead and you require client support for this to work.


Industry best practices for vulnerability scanning and management?

Gartner has updated quite a few research papers that cover this subject in an analytical manner -- http://blogs.gartner.com/anton-chuvakin/2015/12/29/a-quick-update-on-our-research/

However, this is a paywall that many do not have the resources for. 451 Group did an analysis of the CORE INSIGHT product seen here -- http://www.coresecurity.com/system/files/attachments/451-Research-Reprint-Core-Security-Nov14.pdf -- a paper that mentions many other vendors in the space, even though some have changed their names.

The NIST CSF and other primary frameworks provide little guidance other than "to do vuln mgmt" (not a great answer).

My recommendation is to understand what you have invested already in vulnerability management, vulnerability assessment, and vulnerability scanning -- as well as penetration testing and red teaming analysis, red team engagements, and cyber exercises. One point of reference, especially for cyber exercises, is MITRE. I really enjoyed the Cyber Exercise Playbook.

In classic or legacy environments, especially large-installation infrastructures as you describe -- you will typically only see two major commercial vendors play, but perhaps a few others that conjoin for the larger vuln mgmt picture. The best, Tenable, does not see a lot of integration among other vendors which is why Qualys seems to be a dominant vendor -- with Tripwire (formerly nCircle) being the second (although Nessus is the de-facto standard for the number of CVEs it can actively scan for and the deepness and accuracy it can muster, especially with credentialed scans -- Qualys being good at non-credentialed scans). Others, such as Trustwave TrustKeeper and Dell/EMC/RSA come to mind, but only incidentally, perhaps with a structured-program perspective such as compliance-driven.

My cyber model precludes a lot of the above. In my model, which I hope is included in future versions of the NIST CSF or similar standards, the OpenGroup FAIR risk analysis model is at the forefront, with threat assessment driving the whole picture -- where Vulnerability is always 100 percent. This model dictates that a Cyber Operations team be responsible for the vulnerability management and assessment processes, including vulnerability scanning. Modern controls, such as app whitelisting combined with EDR, or reversely, network-behavioral analysis combined with sandbox-exploding malware distribution network detection (or all four) cause a severe issue with vulnerability scanning (and vice versa). Thus, a new model for vulnerability management and assessment is necessary.

When building the concepts for a new framework for vulnerability management and assessment, I have devised a few known-good techniques. The first is to throw out continuous scanning and point-in time assessments. The concept of vulnerability management and assessment is normalized with other vulnerability, exploit, and threat data. SensePost opened my mind to this concept here -- https://www.sensepost.com/blog/2014/using-maltego-to-explore-threat-vulnerability-data/ -- but many other players, including Splunk and the vFeed project, have continued in this vein. The unwritten framework has to do with two primary concepts: red teaming analysis and red-team engagements. Red teaming analysis (RTA) is a technique that involves theorizing the probable threats and targets, with specific weapons, TTPs, and strategic areas (e.g., beachheads) placed into a table and worked through scenarios. This is usually a 6-month planning stage, followed by the red-team engagement, a 6-week hands-on assessment.

In a red-team engagement, traditional vulnerability assessment and scanning tools may or may not be utilized. Primary toolkits such as PowerShellEmpire may not include nmap, Nessus, NeXpose, or any other vulnerability scanners because it already includes advanced-evasion techniques (AET) such as SPN scanning and/or find-fruit scripting. I can imagine many scenarios that do include a Nessus plugin (for a specific, planned test case), or using NeXpose for just fingerprinting. nmap is typically done as slow as possible, with patches and modifications to provide AET, and only port at a time -- although a better use of bandwidth and time might be a tool such as pbscan. Other AET tools that can be leveraged with any of these are SniffJoke and/or McAfee Evader. Commercial tools can't provide these offensive capabilities today -- and I have not seen it on any roadmaps.

Almost any large infrastructure will lead the analysts engaging in RTA and red-team engagements to utilize data-aggregation tools. My top recommendations are LAIR framework, Faraday, and Dradis Pro -- although Splunk can certainly be a great source for long-term or correlation needs (i.e., integration to other data points, such as threat and exploit data). Which brings me to another point, how to integrate secure-configuration management data. Many frameworks talk about secure-configuration management (e.g., PCI DSS Section 2.2), but again, no major guidance is given. The Center for Internet Security offers its benchmarks and some tooling for free, but the CIS-CAT tool and other elements are locked behind their paywall. Some MITRE work through OVAL is available in the FOSS tool, ovaldi, and commercially through Joval. Some vendors do provide a gap analysis between patch, vuln, and config management, but they are difficult to configure -- I think you're more likely to have success in a Cyber Operations program with a platform such as Splunk Enterprise.

Splunk did a good job at explaining some of these paradigms at their recent SplunkSec conference -- https://conf.splunk.com/session/2015/conf2015_CMerchant_Oracle_SecurityCompliance_AffordableSecurityMakingThe.pdf -- and SANS in a recent paper on vulnerability data analytics -- https://www.sans.org/reading-room/whitepapers/metrics/applying-data-analytics-vulnerability-data-36532


This is normal. UDP is sent in bursts, and the small window of time in the screenshot shows a few dozen UDP datagrams in the timespan of one second, which is pretty standard. The answer to how much is too much is simply whenever it is so fast that packets start being dropped.

This UDP is coming externally, whereas a malware threat is internal. Not only was the malware you noticed not executed, but even if it was, it would not result in a burst of incoming traffic, rather you would see it attempt to connect to a C2 (Command and Control) from the inside. UDP is nothing to be scared of. It's a very harmless protocol used for high-speed communication when reliability is not a major concern. It is used in DNS requests, NTP, VPN traffic, video streams, video game traffic, and more. Look on the far right where the destination port and service are specified. Assuming the UDP ports are used for their standard services, the connections are:

1900 - UPnP (Universal Plug N' Play)
5355 - LLMNR (Link-Local Multicast Name Resolution)
5357 - WSDAPI (Web Services or Devices)
67 - DHCP (Dynamic Host Configuration Protocol)

If you are worried that some of these are unintentional, remove the services. None of them are themselves malicious, and the amount of UDP being sent to them is normal.


You should really only sign someone's key if you actually know them, and you trust that the key is theirs.

When you sign it, you are saying that you checked them out, that you know it's their key.

You then figure out "would I trust this person to be as thorough as me in evaluating the identity of other people?"  You might have friends who are careful, or people who you are acquainted with and hold a position of responsibility so you think they might be trustworthy, or they might be a complete stranger, so you wouldn't trust them with a burned out match.  That's when you assign the level of trust.

A web page begging you to sign it could be someone trying to build a sock puppet, false identity, or even stealing someone else's identity.  Worse, they could be collecting the identities of people who are gullible enough to sign a random key with no validation process.


@Jeremy, first thing you need to do is read the PCI-DSS.
That should provide a very good beginner checklist for you. Also, you don't really have a choice in the matter, if you want to accept credit cards you must comply with PCI.

In fact, you'd be better off NOT accepting credit cards, and having other service do that for you - Paypal, payment gateways, whatever. After reviewing PCI you'll probably agree with me...

Here's a few highlights, FAR from complete:

Protect all communications, using SSL/TLS with the certificates, including both encryption and authentication (of the server)
Authenticate all users (a lot of work around password policy and such)
Control access to the application, servers, and database
Never store credit card details, only encrypted PANs
Never store track data, CVV etc AT ALL
Secure your site so its not easily breakable
Monitoring, policies, etc etc and lots more...


Angular application for PCI-DSS certification

Yes, you can use Angular for a PCI certified/compliant application. I've done work for numerous level 1 PCI certified companies that use it. However, there are some different security concerns than a multi-page application.

You need to make sure that the server side code for your web service is secure, but all that that entails is a bit too much for the scope of this question. OWASP is a very basic place to begin: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.

If your web service is on another domain, it must whitelist your Angular application's URL for CORS rules: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. You may also have some strange interoperability between browsers if you have cross domain cookies. Test in all browsers, and ensure it works with strict privacy settings.

In the Angular application itself, first off, you need to make sure you don't persist sensitive information or PII in local storage, session storage, or cookies. Seems obvious: https://auth0.com/docs/tokens/concepts/token-storage#don-t-store-tokens-in-local-storage

You should also keep your session ID, authentication token, or whatever you use to authenticate to the web service in a secure only, HTTP only, strict domain cookie. That means the web service has to give it to the browser as such.

Next, you need to ensure you are handling XSRF. Angular has some built in functionality if you are on the same domain as your web service: https://angular.io/guide/security. There are numerous "gotchas" with that, so you may want to consider creating an interceptor that adds the XSRF to the request header of your API calls that contain user input.

Angular also has a lot of XSS handling built-in, but you should still filter for XSS server side.  A PCI penetration tester is going to require that there is server side protection against XSS and other injection attacks.

Another gotcha that an auditor may bring up is if there's ever sensitive data in the address bar. I've been dinged for that on an audit, because the penetration testers said it could be cached or shoulder surfed.

It can be weird to think about the security of your JavaScript code, because for years we've always been told JavaScript has no security. I think that's what freaks out a lot of more veteran infosec people about it. I had a hard sell to some infosec people, because they weren't thinking about what a single page application really is. If you think of it as a multi-page application that loads only one time, and then only ever makes AJAX calls the transition for them may be a little easier.

Lastly, be sure to keep your framework, libraries, and other dependencies up to date. Check them against known vulnerability databases, and move off of any that are out of security support.


Securing Database Credential in a Field deployed Raspberry Pi

First things first ... physical access is root access.  If someone can physically touch your device, it is no longer your device.

With that out of the way, what can you do to limit the threat?

Lock down access to the AWS to the specific IP (possibly even port security if possible) ... this way even if someone steals the creds out of the python script they can't do anything without using the same connection it was originally on.
Lock down the DB User to the min Read/Write access required by the script so that if someone gains access they cant dump the entire database and/or drop tables. (see also Database Trigger)
Write a remote API wrapper around the Database access (see also redis pub/sub) so that the RPi can only do commands allowed by the API, and remotely log all API request good & bad.
Remotely deploy code to memory only.  If you setup a bootstrap to pull code to a ram drive (see also loop0), run it, and delete the local copy ... it should only be accessible if the thief can steal it while maintaining power.

Again, you can't fully protect your AWS but you can harden it and buy yourself time to invalidate the User or API key associated with the RPi.  Just make sure you regularly check logs for nefarious activity.


Disclosure: I work for an anti-virus vendor.

Because most anti-virus engines were born as protecting endpoints, and even now for many of them endpoint protection is major part of business, the modern anti-virus engines are optimized for scanning endpoints. This optimization includes many things, such as:

Not scanning the files which couldn't contain infections which can infect your computer;
Remembering which files were scanned, and not scanning them again unless the files were modified;
Optimizing scans for the file types when possible - for example when scanning executables, only certain parts of it need to be scanned. This minimizes disk reads, and improves performance.

A common misconception is that AV engines use hashes. They generally do not, for three reasons:

First is that getting around hash detection is very easy and doesn't require modifying the actual malicious code at all;
Second is that using hashes does not allow you to implement any kind of proactive protection - you will only be able to detect malware which you have seen;
Calculating a hash requires the whole file to be read, while for some files (such as executables) this is not necessary. And reading the whole file on non-SSD hard drives is expensive operation - most AV engines should scan a large clean executable file faster than calculating hash on it


What is the difference between single hardware firewall and router?

A router can be some simple very cheap device to connect a home to the internet. But it can also be some really expensive device managing the traffic on the backbones of the internet. Similar a firewall can be some simple software to filter packets based on port and IP address only which easily fits into the home router. But a firewall can also be something doing deep inspection with a high performance in which case you usually have an expensive appliance just for this task.


How do I check if my router is patched against the KRACK exploit?

From my point of view, you only have two options wait to a vendor response or check with a tool.

If you prefer to wait, check this list. The list is accurate and updated frequently.

On the other hand, I think that you should check yourself the router using the krack-ft-test, released by the author who discovered the vulnerability. Remember that this tool only tests the vulnerability you are not doing and aggressive attack.


Email clients (like Thunderbird) generally don't insert origin IP addresses (or other header lines) into sent emails.

Usually, if such a change takes place, it's done by the mail server that the email client connects to.

In this case, I tried a test email (Sent via Gmail on Thunderbird), and my IP does not appear in it. You should verify that this result is the same for you - Gmail will have multiple mail servers, and they may behave differently (e.g. for testing).

Edit: Oops, I'll address the "how to hide" part of the question.

Short answer: You can't hide your IP from the email server you connect to.

Long answer: You can't hide your IP from the email server you connect to, because by definition, you need to connect to it to send your email, and once you do that, it knows your IP address. Once it has that information, it can do anything it wants with it - log it, store it, alert the police, or insert it into the email header.

The only thing you can do is to connect to the mail server from an IP address that can't be linked back to you. So this means using a privacy-oriented network tool like Tor, or a trusted VPN. Or, use public WiFi, e.g. at your local library or Starbucks etc.


Can the Windows lock screen be attacked with software?

You ask about cracking, a long and complex 15+ length password will render crackers useless within your timeframe. This bypass method takes 15 minutes at most:

You can disable autorun, you can put a password on your BIOS.
But a single BIOS reset (requires 2-5 minutes of unmonitored physical access) will remove the BIOS password, allowing an attacker to BOOT the computer through USB/CD with e.g. KON-BOOT. This attack will temporarily allow any password with your accounts without resetting your old password.
The only protection from this that I know of is system encryption e.g. VeraCrypt.


Are there special attack vectors for statistical databases?

I might be mincing terms here, but technically no, a statistical database shouldn't be vulnerable to SQL injection, because statistical databases tend not to use SQL as its query language. They tend to use variants of the language like MDX or DMX. Then again, some do support SQL though so...

However, since they do accept input in the form of a language they certainly can be vulnerable to injection because its not really up to the database or its server to prevent injection. Its up to the application calling into the database to properly protect against injection.

There are varying degrees of damage involved here too. In most cases you can't insert data or delete data as these databases/cubes/models tend to be read only, however it could be possible to change the intended result set and get more information than expected. I would expect this to be possible in poorly developed reporting applications.


Password verification scheme (used in eg. MS Office) - more secure than just a hash?

This scheme is ok, but it's basically just a variant of a salted hash. These are generally considered old practice. Furthermore, this scheme is more complicated (more surface area for potential bugs) and relies upon multiple cryptographic algorithms being unbroken.

Modern good practice is that passwords should be stored using a slow key derivation algorithm such as PBKDF2 or bcrypt. These ensure that lookup tables are infeasible, and that cracking all but the weakest and most common passwords is extremely expensive.

I wrote an answer a while back explaining a bit of the history of password hashing and why we now use slow KDFs.


How should one prepare himself for a job interview for penetration testing?

In my experience these are my following observations:

  Should it revolve around the ability to verbally explain attacks at a
  non-technical\technical level?

Yes. Absolutely it should involve a technical level. Non-technical explainations are a bonus, you will, as a pen-tester be involved in meetings with people who know nothing about what you're doing and will get angry if you don't explain it simply. The kinds of people who usually hire pen-testers however realise that usually you get one or the other (people skills vs technical skills). If you can demonstrate both, you are way ahead of the competition.

  Should it focus on network, system and web app attacks? Social engineering? Attack vectors?

The only attack that probably won't be questioned (largely because it rarely comes up in pen-testing jobs) is Social engineering (note, stuff like phishing attacks and the like may come up). A good interviewer will ask you a number of technical questions, and also provide you with a workstation to demonstrate some attacks, these can include basic Web-app exploitation as well as system/network exploitation. Things like SQLi, XSS etc should be known from memory.

  Should it revolve around countermeasures to attack?

Not necessarily. However being able to demonstrate such knowledge should usually go hand-in-hand if you understand the attacks in depth.

A useful snippet from pentesterlabs blog is below explaining (how at least one professional tester conducts interviews):

  Before the interview (or even before you read the resume), it's good
  to have a basic opinion on someone's skills... I wrote a simple
  website with 20 questions to get a quick feeling of who I'm talking
  to.

  The questions are simple but allow to detect people with no security
  knowledge. Below are 2 of the 20 questions so you can see what I'm
  talking about:

unmd5 is the PHP function used to retrieve the clear text of a md5 ? True/False
Windows passwords are stored in C:\Windows\System32\drivers\etc\shadow ? True/False

  If someone passes this test, the real technical interview can start.

  As always, you will have the normal security questions (I guarantee
  most security companies ask for these):

explain a tcp handshake
how Windows passwords are stored?
what is a cookie?
opinion on disclosure?

  From my experience, I think it's better to ask people to explain
  things than just to ask them what it's. You can really see what level
  of understanding people have of a problem...

  For example, with Cross Site Scripting, you can have the following
  responses:

"it's a problem of filtering and it allows an attacker to inject script in the page"
"it's a problem of filtering and an attacker can display/run arbitrary code in victims' browser"
"it's a problem of output encoding and can be used to inject Javascript or HTML in the page sent back to victims"
...

  That way, you're able to see if the person really understands what's
  going on and how he will be able to explain it to someone else.

  You need to have 2 types of questions:

questions based on memory: "what port is used by X", "what nmap options do you used"
questions based on reflection: "how will you solve that problem"

  I also have my favorite set of questions:

"You're going to PentesterLab's website, explain what happens...", that way you can see someone's knowledge of TCP/IP, DNS, HTTP, SSL,

  ...
      "What is the last cool thing you learned/read", that way you can see what people are interested by and where they at

  After this test, another interview is setup with hands-on test (only
  if the person did good enough obviously), it's currently the web
  application of the exercise "From SQL injection to shell" and it's
  used to see how people think and behave with a computer.

  You can see a lot of different things:

what people use for desktop
how fast someone is with his computer
how people solve a problem
if people bring a working laptop (yes it happened, someone came to an interview with a broken gentoo...)
learn from people: sometime people show you cool tricks you didn't think of
...

  Obviously, not everyone (actually only one person did it without any
  help so far) knows how to exploit a SQL injection manually (why do you
  think I created PentesterLab). But during the test, we help people and
  show how things work to see how they can learn new things and
  incorporate information into their way of thinking.

Source: pentesterlabs
Related reading: pentesterlabs how to get your first job

Hope that helps!


How would I safely store a password locally?

Would it protect the passwords from another application which is potentially malicious?

No
DPAPI (of which CryptProtectData is a part) cannot protect against a malicious application running under the same user. This is because any application running under the same user can request decryption of a DPAPI encrypted blob. It is possible to give DPAPI some additional entropy while requesting encryption, and then only an application that knows the additional entropy will be able to decrypt the blob, but you run into the original issue again. Where do you store the additional entropy, such that a malicious application cannot access it?
The only situation in which DPAPI offers any real security is if you're device gets stolen (or confiscated by some authorities) and you don't have FDE. In this case, provided that your Windows password is strong enough to resist bruteforce, the stored DPAPI encrypted data cannot be read.
In the end, it's just as @Polynomial says in the linked answer:

Any procedure you choose to obfuscate passwords is an exercise in futility against any half-determined attacker, so at most you're creating an illusion of security.

I have a few ideas, such as hashing the password and storing it to a file

The main problem here isn't that the hash can be cracked, it is that cryptographic hashes are irreversible. So when you need to log in, you won't be able to recover the password from the hash. If you design the application to send the hash instead of the password, the hash effectively becomes the password, and you're back to storing it as plaintext.

Edit: As clarified by OP in comments, the application in question is the server, not the client. For a server, there is absolutely no reason you should store the password in a reversible format. Hash it with a strong password hash like bcrypt or Argon2id and store the hash only. (Warning: Do not try to implement the hash functions yourself. Use a well-known and tested implementation.)


A message authentication code (MAC) is produced from a message and a secret key by a MAC algorithm. An important property of a MAC is that it is impossible¹ to produce the MAC of a message and a secret key without knowing the secret key. A MAC of the same message produced by a different key looks unrelated. Even knowing the MAC of other messages does not help in computing the MAC of a new message.

An HMAC is a MAC which is based on a hash function. The basic idea is to concatenate the key and the message, and hash them together. Since it is impossible, given a cryptographic hash, to find out what it is the hash of, knowing the hash (or even a collection of such hashes) does not make it possible to find the key. The basic idea doesn't quite work out, in part because of length extension attacks, so the actual HMAC construction is a little more complicated. For more information, browse the hmac tag on Cryptography Stack Exchange, especially Why is H(k||x) not a secure MAC construction?, Is H(k||length||x) a secure MAC construction? and HMAC vs MAC functions. There are other ways to define a MAC, for example MAC algorithms based on block ciphers such as CMAC.

A MAC authenticates a message. If Alice sees a message and a MAC and knows the associated secret key, she can verify that the MAC was produced by a principal that knows the key by doing the MAC computation herself. Therefore, if a message comes with a correct MAC attached, it means this message was seen by a holder of the secret key at some point. A MAC is a signature based on a secret key, providing similar assurances to a signature scheme based on public-key cryptography such as RSA-based schemes where the signature must have been produced by a principal in possession of the private key.

For example, suppose Alice keeps her secret key to herself and only ever uses it to compute MACs of messages that she stores on a cloud server or other unreliable storage media. If she later reads back a message and sees a correct MAC attached to it, she knows that this is one of the messages that she stored in the past.

An HMAC by itself does not provide message integrity. It can be one of the components in a protocol that provides integrity. For example, suppose that Alice stores successive versions of multiple files on an unreliable media, together with their MACs. (Again we assume that only Alice knows the secret key.) If she reads back a file with a correct MAC, she knows that what she read back is some previous version of some file she stored. An attacker in control of the storage media could still return older versions of the file, or a different file. One possible way to provide storage integrity in this scenario would be to include the file name and a version number as part of the data whose MAC is computed; Alice would need to remember the latest version number of each file so as to verify that she is not given stale data. Another way to ensure integrity would be for Alice to remember the MAC of each file (but then a hash would do just as well in this particular scenario).

¹  “Impossible” as in requiring far more computing power than realistically possible.


SQL injection that bypasses website's firewall that filters table by its prefix

TL;DR, no.

If the WAF is configured correctly and doing its job, you have no way of injecting that info. Javascript allows variation of "script" for XSS etc onclick=alert(XSS pwn'd!) instead of <script>alert(pwn'd!)</script> etc), but SQL does not. SQL injections are, by and large, very fickle and require very precise queries with very precise order. If the WAF is blocking union or select, you're probably dead in the water. You might be able to find a fancy way around it, but unless the client is paying big bucks and you're ready to spend a week on it, it's probably best to move on to another vulnerability.

It's unfortunate - I've done many penetration tests where compensating controls are used in place of secure coding. However, frustrations and bad practice aside, it is what it is.

PLEASE NOTE this doesn't mean joomla, PHP and whatever else doesn't have other vulnerabilities that can be exploited. Exploit-db.com is your friend here. Joomla 1.5 has 86 results in exploit-db.com, and PHP 5 has undoubtedly hundreds if not thousands. Please remember: penetration testing and vulnerability scanning is all about ENUMERATION!


How do you log into Amazon Web Services if you lose your phone which has Google 2-factor authentication set up?

You fix the typo in the url

  https://aws.amazon.com/forms/aws-mfa-support/

(notice the 'r' in 'forms' that was previously missing


When to use envelope encryption and when not?

In general, the enveloped encryption is more flexible with only a small bandwidth overhead, so there's no reason not to do it?
You get flexibility in the sense that:

If you happen to need to add a second decryption service, then you can simply re-encrypt the DEK for that decryption service rather than needing to re-encrypt the (presumably much larger) data payloads. For example you might in the future want a disaster recovery site with different encryption keys from the primary site.
If your organization has a key rotation policy (ex.: all encryption-at-rest keys must be rotated every year), then it's generally easier to implement this as enveloped data where you need to re-encrypt the DEKs for a new KEK, as opposed to needing to find and re-encrypt all the data.

A special case of this is if your decryption service gets hacked and you have to roll over your master encryption key in an emergency situation.

Implementing this fully involves more than just the encryption format since you need to worry about where you're storing the DEKs and have a procedure for pulling them down and re-encrypting them. But the point is that choosing enveloped data now gives you all sorts of options down the line that you wouldn't have otherwise.


Most email virus require to be executed through either of these methods:

The email software and/or the operating system automatically runs the file when it sees it. This is the case for pictures that exploit flaws in the picture-rendering libraries: the software processes the picture automatically (if only to show it as a thumbnail), triggering the exploit.
The gullible human user is induced into running the thing.

Most email virus follow the second path, since it is much easier. Flaws in software libraries are reported and patched by vendors; flaws in the human brain are never fixed. Typically, the file will be called ".zip.exe" (the user will just see ".zip" and think "this is a Zip archive, not an executable), or ".scr" (the user is not aware that "screensavers" are actually executable files in the Windows world). When the virus is of the second kind, downloading the file is safe, as long as you take care not to execute it. Beware of double-clicking it !

If you can arrange for a transfer without downloading it on your work machine, this would be safer. For instance, if you can access your emails through a Web portal, then do that from, say, a machine running Linux (could be a VM). As a rule, Windows  virus don't impact Linux, and vice versa.


Paypal supports TLS 1.0, 1.1, and 1.2.   If your browser advertises that it would like to use TLS 1.2, then that is indeed the TLS version that Paypal will choose to connect with.   If, however, your browser suggests to Paypal's servers that the highest TLS version it supports is 1.0, then Paypal will happily connect using that protocol version as well.   I imagine that this is exactly what whoever was demoing BEAST did.  Set their browser up so that it would only use v1.0, and not 1.1 or 1.2.


How to get rid of geolocation info on linux?

Got it. The Linux system uses IPv6 while my Windows System isn't.

Also the Test-Sites I checked only checked the IPv4 - Adress telling me everything is right


Difference in Web Language Compilation and Execution

There seems to be a bit of confusion here, I will start by clarifying a few things.

When I say XSS I simply mean unsanitized and unescaped code being passed to the server.

This might be what you mean, but it isn't what anyone else means.  XSS is the injection and execution of javascript on the browser.  This injected javascript can come from the server (stored) or the browser itself (reflected).

...you could also have a piece of information included in a web page which also contains valid PHP code such as <php phpinfo(); ?>. The server parses over this code and executes it as valid PHP...

No, that isn't correct.  It takes more than just including PHP in a HTTP request to inject code on the server side.  If what you were saying were true, it would be a security disaster.

To answer your questions:

...at what stage does the code have to be within the page before the browser will treat it as valid code for the language?

I would say that if it is part of an attack it would not be included in the page at all.  If someone is trying to attack a website, they will most likely do it from the HTTP request level using an HTTP proxy.  This is beyond the scope of a page.

Injecting code on the server requires some specific vulnerabilities in the code.  Give this article a read to get an idea of how it would happen in PHP.

Could you have a XSS vulnerability turn into code execution because someone injects PHP code instead and the server parses it?

No - server side code injection and XSS are two totally different things.  An XSS vulnerability doesn't become server side code injection just because you provide PHP.

Would this be different for something like a stored XSS* vulnerability vs say a reflected XSS vulnerability?

I don't really understand what you are asking here, but the answer is probably yes.  Server side code injection and XSS are totally different.

Is there any difference between other languages such as aspx / asp with relation to PHP vs something like Javascript?

Again not really sure what you mean.  There are obviously differences between these languages.

I would focus on learning the difference between XSS and server side code injection - I think a firm grasp of these concepts will clear up a lot of the confusion.

Best of luck!


I think this comment from the code you posted sums up my thoughts:

    // We need to know if braces are correctly balanced.
    // This is not trivial due to variable interpolation
    // which occurs in heredoc, backticked and double quoted strings

Keep in mind that the result of improperly executing the code check is a remote code execution vulnerability.  Working on non-trivial items is of course the norm for engineers, but if you are working on a task that is extremely difficult and a mistake leads to the most serious kind of security vulnerability - well, clearly that is a recipe for disaster.  In fact it's worth pointing out that the comment you posted was the authors second attempt at this.  His first attempt at contained at least one mistake that (presumably) was vulnerable to "sandbox escaping" and required him to start over.  I'm certainly not going to trust the security of my application to a one off script written in a comment box on some random page on the web.  Especially since (unless I'm missing something) this comment happens to be on a page describing a language built-in that does the exact same thing.  I would trust the language built-in before some random guy on the internet.

Regardless of whether or not anyone has found an exploit yet, it doesn't change the fact that this is generally a bad idea in the first place.  What if there are other escaping options that the author hasn't thought of?  For instance, plenty of exploits out there have relied upon confusion over different encodings.  It might be possible for an attacker to inject in a brace using an encoding different than the one in the file, but still supported by PHP, which will therefore not register as a brace in his checks but will be recognized as such by PHP, allowing an attacker to break through the brace balance check.  Granted, that particular attack avenue may not actually be possible, but I'm mainly trying to emphasize the general point.  There can be many hard-to-catch "gotchas" in situations like this, and the result of missing one of them in this code is a remote code execution vulnerability.

When faced with "Get it perfect or be extremely vulnerable" my first preference is "Just don't do it".  That is followed up by a strong "don't trust a random comment on the internet", especially if there is an easily-accessible language built-in that does exactly the same thing but (presumably) securely.

Edit to add.  It's worth making a comment about eval.  You said "I know eval is insecure, but"...  This is not strictly true.  eval usage is generally frowned upon for a few reasons:

If nothing else it tends to have poor performance
If used improperly it certainly can create real security issues
It generally violates best programming practices

However, like any tool, it can have its time and place.  So to be clear the issue isn't that eval is insecure.  The question is whether or not eval is being used securely (and properly) here.  For all the reasons outlined above I don't think that it is being properly used here, but that is different than a blanket "eval is insecure" statement.


Can any App Store app access all of my passwords?

No. Just because there is an alias to something from an app's sandbox container does not mean the App has access to it -- that's still controlled by the app's entitlement list (and I strongly suspect Apple would reject any app that requested direct access to a user's keychain files). Also, even if it could access the file directly (as a non-sandboxed app could), the passwords are encrypted, so it'd still have to get past that layer of security.


How to tell if human is using website or automated script?

The most common method is probably a hidden field, bots tend to fill these but humans don't.

Also common is to use a captcha of course.

Then some people use JavaScript to detect page events that typically only happen in a real browser. Such as a click event in a form field.

It might also be possible to get clever with timing things in the browser, again using JavaScript. Humans will type at a much slower pace than bots for example. They will also take much longer to fill in and submit than a bot.


What CWE can be used to best describe ASLR being disabled on a process?

CWE doesn't enlist lack of ASLR explicitly as an entry, but I believe it definitely comes under "Security Misconfiguration" CWE-815 as Rook has stated above.

Additionally, I wanted to add that Buffer Access Using Size of Source Buffer CWE-806 clearly recommends it as one of multiple necessary measures for system hardening against overflow based attacks. The exact statement is as follows:-

  Phase: Operation
  Strategy: Environment Hardening Use a feature like Address Space Layout Randomization (ASLR) [R.806.3] [R.806.5].
  Effectiveness: Defense in Depth
  This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Also, although the OWASP Project identifies it as a Wiki Page and weakness, it doesn't state which category it falls under at this point of time (Seems like a good thing to contribute to). :( Ref: https://www.owasp.org/index.php/Address_space_layout_randomization_%28ASLR%29


How to see what happens when a usb is inserted

Well that edit means a new answer.

Yes you can. You can monitor the individual bits sent to and from the USB stick in many ways. Then you decode those bits, and follow the rabbit down the hole, so to say.

A quick google search turns up plenty of things. Search for USB analyzer

Although if you're on windows, Microsoft released a first party tool: https://msdn.microsoft.com/en-us/library/windows/hardware/dn741264(v=vs.85).aspx

These tools will allow you to follow the entire stack as it comes off of the USB and watch an infection happen real time. It's actually pretty cool to dive into.


Inadvertent clickjacking on page causes LastPass login dialog to appear.

A basic phishing attack springs to mind.

However, a malicious site could of course construct a LastPass login box themselves and hope the user uses it to login.

I suppose the advantage here is that the LastPass box will only appear if the LastPass extension is installed, plus it may have the advantage of always being current and that of the username being pre-filled in because it is from the actual LastPass dialog generation code.

It is difficult to answer further without seeing a full POC in action.


What is the weakest scheme in common use for password hashing?

Depending on your definition of "common," DES with passwords truncated to 8 characters (for which rainbow tables exist).


How to view extension privileges in Firefox?

Read this document. Relevant excerpt (page 3):

  The Firefox platform has no mechanisms to restrict the privileges of add-ons. The add-on code is
  fully trusted by Firefox. The installation of malicious add-ons can result in full system
  compromise. There is no security measure to restrict the intercommunication between add-ons.
  As a result an add-on can alter or modify another add-on in the background. There is no security
  policy or sandboxing ability of XPConnect and XPCOM components which is a serious flaw in the
  security
  model. Firefox does not have any type of restrictions on malformed Cross Origin
  Resource Sharing and socket creation. Some exploitable vulnerabilities are platform
  independent.

So there is no way to show per add-on permissions because there are no permissions to show. In the Firefox security model, each add-on is roughly equivalent to a piece of native code, which can, by definition, do whatever it wants. This is similar to the situation with signed Java applets.


Why do the banks all use weaker TLS suites?

I guess the most concise answer to this question is: They are insured.

Currently industry standards don't require PFS and therefore insurances pay even if the bank had no PFS. There was a similar question on 30c3, about why the banks are using Windows XP as their operating system.

Those standards can also be a reason why banks can't implement new methods like PFS as fast as companies like Twitter, when every security measure needs to be audited and certified.

Another point would be that most attacks don't base on breaking the encryption, but on targeting the computer of the user itself.


The situation in TLS 1.3 regarding encryption of alerts is no different then with TLS 1.2. The current draft 26 includes the same statement as you can find in the RFC of TLS 1.2:

  Like other messages, alert messages are encrypted as
     specified by the current connection state.

In Appendix A you also find the state diagrams which have additional information:

  ... clients may send
     alerts that derive from post-ServerHello messages in the clear or
     with the early data keys.  If clients need to send such alerts, they
     SHOULD first rekey to the handshake keys if possible.


Trick client into connecting to unsecure evil twin Wi-Fi access point

The user's device can distinguish the Evil Twin from the original AP

In this case the attack can't work if the deauthenticated user doesn't connect manually to your evil twin (And he doesn't notice it's not protected)


AES-256 decryption after key destruction. Possible or not?

In theory, you could try to brute force the key and recover the data.  In practice, that's extraordinarily unlikely to be successful as it would be expected to take a very, very long time.

Per Wikipedia:

  AES permits the use of 256-bit keys. Breaking a symmetric 256-bit key by brute force requires 2128 times more computational power than a 128-bit key. Fifty supercomputers that could check a billion billion (1018) AES keys per second (if such a device could ever be made) would, in theory, require about 3×1051 years to exhaust the 256-bit key space.

Keep in mind, the universe has existed for about 1.38×1010 years.  Supposedly, a quantum computer could reduce this substantially, but it would still be expected to take longer than the universe has existed.

Of course, you could get really lucky (like win the lottery every week for the next decade lucky) and brute force it in a year or two, but if I were you I wouldn't waste the time or effort.


several questions about linux kernel debugging - memory examination

I have never debugged the kernel, so I may be wrong, but I believe that what you are seeing makes complete sense.  Let's go through it:

  add    BYTE PTR [rax],al

  why is that? is this because I'n in virtual machine?

That is what I would actually expect from 0x0000.  This is easy to test:

[~]$ uname -a
Linux haps 4.7.6-1-ARCH #1 SMP PREEMPT Fri Sep 30 19:28:42 CEST 2016 x86_64 GNU/Linux
[~]$ perl -e 'print "\x00\x00\x00\x00"' > pp
[~]$ ndisasm pp
00000000  0000              add [bx+si],al
00000002  0000              add [bx+si],al

So yeah, 0x0000 is add into the first byte of RAX (i.e. al).

  but how to list permissions to these pages - rwx ?

I will argue that that does not make sense.  A common misunderstanding is thinking that the kernel runs as root, that completely untrue.  The kernel runs in kernelmode, and everything else runs in usermode (unless it is in the middle of a syscall, that is).

In the global page directory the pages used by the kernel have the DLP (Descriptor Privilege Level) set to 0, meaning kernelmode.  All userspace used pages have the DLP set to 3, meaning usermode.  When the CPU is executing a userspce process it is in usermode, therefore if it tries to access a page that has a DLP of 0 (or 1 or 2, but those are not used in Linux) then the CPU will shoot an exception (an interrupt) and tell the kernel to clean the mess.  The kernel, in turn, will simply queue a SEGFAULT in the signal queue of the process that is currently active.

In summary, any userspace process that tries to access those pages will get segfaulted.  It does not matter if the process is run with root privileges or not.  Therefore it does not really make sense to give a set of permissions to the memory pages that are used by the kernel.

Extra note

You may ask: but what about /dev/mem?  That's kernel memory that can be seen from userspace.  Well, reading and writing to /dev/mem (or /dev/kmem) provokes a syscall.  And something like copy_to_user or copy_from_user is called to pass data between DLP 3 and DLP 0 pages.


Where is Bitlocker encryption key stored in USB?

Have you checked hidden files?

"The key will be saved to the USB drive as a hidden file with the .bek file extension. You can see it if you show hidden files."

Source -- https://www.howtogeek.com/262744/HOW-TO-USE-A-USB-KEY-TO-UNLOCK-A-BITLOCKER-ENCRYPTED-PC/

(Doesn't look like this is a duplicate)