Situations that a firewall should use rule for all packets When should a "match all packets" rule  be used (instead of chain policy)?

I think that this should be used in real time applications like audio streaming or video broadcasting. Are there other situations?

Whenever it's the easiest way to define your rules.

Modern firewalls are more than capable of dealing with dozens, hundreds or even thousands of rules without much of a performance hit, so the general rule is to make your rules easy to administer and to make sure your device performs the function you intend.

That means; if your device only does one job with one type of packet, set up your defaults to deal with that type of packet and you're done. If however you need to deal with multiple types in various ways, well, separate policies may be easier to deal with rather than letting things fall through to your default because you can change their priority in your chain, add rules afterwards, etc. - doing it that way also means that your device does nothing you don't explicitly intend (assuming your default is deny all).

For real-time streaming, video broadcasting and the like we have QoS which on most devices you can include or associate with your streaming rules.


Content Security Policy Header not stopping attack I created a simple test web application to test the use of the content security policy header. I included a vulnerability in my test app, such that submitting a basic XSS payload with script tags would be reflected back in full and execute a javascript alert...simple stuff.  I included a basic CSP header:

Content-Security-Policy: default-src 'self'

I assumed this would stop the XSS, due to "CSP solves this problem by banning inline script entirely" https://developers.google.com/web/fundamentals/security/csp/

But, the js alert is still popping. I was able to verify that the header is being returned in the server response as expected. I tested with several up-to-date browsers (chrome, firefox, ie11). I applied the header in iis as follows:

# IIS Web.config
<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Content-Security-Policy" value="default-src 'self';" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

Is my implementation incorrect, or are my expectations wrong here?

[from comment] ... IE was not working, but, does ie11 even support this header?

According to can i use content security policy there is only partial support in IE11: only the sandbox directive is supported and the header needs to be specified as X-Content-Security-Policy. Thus, no support in IE11 for what you are trying to do.


Does a self-hosted VPN (openvpn) at home encrypt traffic for my ISP? Title says it all.

If I host my own VPN at home (using openvpn), and connect my devices to it, will my ISP be able to see the contents of my traffic?

Your setup is not fully clear. But given the description I assume that you create your own OpenVPN server and use it as an VPN endpoint when you are outside of your local network. Any connection to the internet from the client will then send protected by the VPN and invisible to the ISP to your home. At your home the traffic will then leave the VPN (since your home is your VPN endpoint) and will be send without further protection from your home to the internet - i.e. the ISP can see where on the internet your traffic is going and in case of unencrypted traffic can also see the contents.


Is it a security issue that Thunderbird only logically deletes emails? I have several e-mail accounts configured in Thunderbird. I just wanted to move an e-mail from one of my e-mail accounts [A] Trash folder to another accounts [B] Inbox folder. Because the moved e-mail has been lost, Thunderbird doesn't shows it, but here's the catch: Another email appeared in the Inbox of the [B].

I found all my outgoing emails in /home/USER/.thunderbird/vzbrrs3a.default/ImapMail/imap.googlemail-1.com/[Gmail].sbd/Sent Mail, even the ones I deleted both from the sent mail folder and the trash folder.

Why does Thunderbird keep deleted e-mails?

Logically deleting is very common in many application that handle huge amounts of data for performance reasons. This includes other email programs for example Microsoft Outlook and even database servers for example MySQL.

Even files, that you delete from your hard disk, are not actually destroyed. The space is just flagged as empty and may be override in the future.

In Thunderbird, compacting folders will get rid of those deleted emails. At least for me, Thunderbird regularly asks me whether I would like to do that.

I consider this problem a minor issue because an average user may not be aware of it.

An attacker needs read access to the storage folder in order to exploit this behaviour which is one of the worst case scenarios to start with. If you are concerned about theft of your notebook or other forms of illegal physical access, encrypting your hard disk may be better approach.


Do mobile OS's provide crypto-quality randomness? Which mobile OS's provide a primitive to generate crypto-quality randomness that applications can use?

On desktop systems, these features are pervasive.  Unix provides /dev/urandom.  Windows provides CryptGenRandom.  Do mobile OS's provide something like this?  Do they provide any support so that developers don't have to write their own code to collect entropy from multiple sources and combine it to get a seed?  (That's something that's error-prone and non-trivial for developers, so I'm looking for support from the platform -- whether it's the OS, or libraries, or something else.)

I would welcome answers that specify a mobile OS, whether it does/does not provide this support, and if yes, what the interface for developers to use is.

iOS on iPhone provides entropy from all standard inputs like accelerometers, compass, radio baseband, as well as from certain parts of the circuitry which picks up interference at all levels. Random bits are available to app developers via the SecRandomCopyBytes() function.

I don't have info on other platforms.


Can a hacker access smartphone data while locked? Imagine you leave your smartphone in a hotel room for half an hour.

Screenlock is on. Latest security updates are installed.

How could somebody steal your data from the device given enough expertise is given? (being realistic though)

Like:

files
passwords saved in browser
clipboard memory
address book and call data
biometric data i.e. fingerprint data

This scenario does not consider stealing data stored on the SIM card (assuming the screen lock is not saved in an unencrypted plain text string there irony)

This depends on the implementation and configuration of your smart phone, but smart phones can be pretty secure. In the FBI–Apple encryption dispute, the FBI took more than a month and spend more than one million dollars to access the data on an iPhone.


Getting lots of NXDOMAIN response Currently I am analyzing the DNS logs from various Windows servers. I am seeing lots of NXDOMAIN response from the DNS server. When I looked into the query field, it is something like 'NHCNEBDBEBEEBFEDCDCDFDBDEDEDDDCA' (strings of random length and all in caps). After looking around I came across this which explains it is the DNS anti-spoofing testing. I want to know whether it is completely normal and is performed by google chrome or there is something fishy like DOS attack going on.

Edit: Windows server are also acting as DNS servers and both are present behind the corporate firewall. Currently I am using Splunk Enterprise Security as SIEM tool. Splunk is raising the notable event "Excessive DNS Failures"

I verified that whenever Google chrome browser is launched, it generates series of such random queries (around 6-9) which is forcing the DNS server to return NXDOMAIN response. The link in the question helped me to verify the chrome behavior.


Privacy/Security with SSH Tunnels and QuickVPN I currently use QuickVPN, however, it does not seem to route my web browsing traffic through a tunnel. Am I correct? It only opens up a tunnel for accessing windows shares and documents back at the office, right so only they are secure?

If I wanted to also mask or make my internet browsing secure and private I would need to setup a SSH tunnel/socks?

This configuration is known as split tunnelling - your VPN client only sends traffic destined for the office network over the VPN, and saves money in bandwidth utilization (and speeds up your web browsing) by not routing traffic destined for the internet over the VPN and out through the office web proxy.

A SSH tunnel is a point-to-point connection, not a method of internet access, and a SOCKS proxy is a server that acts as a go-between between your PC and the internet and is generally not available to home users.

Secure and private browsing is a pretty deep and broad field of knowledge - but it will require endpoint security (security software on your PC or a firewall you set up between your home network and the internet.) Home and home-office users generally rely on security software installed on their PC - if you have a Windows PC, you will need, at a minimum, decent anti-malware ("AV") and firewall software.

For secure browsing, here is a good overview for beginners.


How to judge website security? How can I know if visiting a website is safe?

Is a scan with virus total good enough? If it says that the website is clean then can I be sure that I won't get hacked by visiting it? Could a website still be unsafe to visit even if virustotal says it is clean? Is it possible that a website has malicious code that is not present in virustotal database?

What about addons like WOT (web of trust)? Can their assessment of websites be relied on?

Neither a virus scan nor a web of trust can judge the security of the website. WOT is just about the trust others have in this site, which says nothing about the security of the site in general and especially not of the security at the very moment. A virus scan will also not find typical coding problems like SQL injection or cross site scripting nor will it give you any clue how well your data are protected.

  How can I know if visiting a website is safe?

You don't. Which already starts with the problem what "safe" actually means?

Is it that the site itself does not try to deliberately attack you (phishing or malware), i.e. safe to visit.
It is about privacy, i.e. how much the site will track you? Is it about the safety of the data you enter into the website, i.e. safety of stored passwords and credit cards, no deliberate sharing with others etc.

  What about addons like WOT (web of trust)? Can their assessment of websites be relied on?

This is more like the rating of products on shopping sites or the rating of restaurants. If everything is bad the site likely behaves in a bad way. If everything looks good it can actually be good right now, it could have been good once, the rating could be deliberately manipulated ... So it is some kind of indicator but nothing you can fully rely on.


Can you tell if a page does exist even if it throws a 404? Is it possible to determine that a page actually exists when it is designed to throw a 404 NOT FOUND?

On my server, when a request to a script is made while passing invalid parameters, I am throwing a 404 http status code because I don't want those with no knowledge of the system to know the page (public URL) exists. I am hoping that throwing a 404 will make an attacker think the script does not exist.  No resources on the server itself actually direct to the script, it would all be from external requests.

What I really want to know is, from just the response, would someone be able to tell the difference between a page that does not exist and a page configured to return a 404?

The response headers when making an invalid request to the script do indicate a http status of 404, and not a http status of 200 with a 404 page displayed.

Below is the response header I am getting when I make an invalid request.

HTTP/1.1 404 Not Found
Date: Fri, 27 Jan 2017 23:32:28 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
X-Powered-By: PHP/5.4.16
X-XSS-Protection: 1; mode=block
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

EDIT:
Below is the response header I am getting when I hit a page that truly does not exist.

HTTP/1.1 404 Not Found
Date: Tue, 31 Jan 2017 19:08:06 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Content-Length: 203
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

Throwing 404 error for every invalid request could be questionable, an attacker may start suspecting this behavior specially if he knows the service he is targeting.
Does this help protecting your service ? this really depends on the perseverance of the attacker.

Edit:
The attacker can detect the difference if you don't craft the 404 response header properly as the server would do
Here is a PoC for Java server case (Tomcat8):
This is a 'truthful' 404 status returned by the server itself for any not found resource :

Content-Language:en
Content-Length:1026
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:15:54 GMT
Server:Apache-Coyote/1.1

This one is returned by the servlet :

Content-Language:en
Content-Length:992
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:18:04 GMT
Server:Apache-Coyote/1.1

You notice the parameter's value of "Content-length" in both cases, this one could attract the attacker's attention.


Man-in-the-middle SSL generation on request possible I am doing some research on man-in-the-middle focusing on SSL  in particular.

I have been looking into  generating a certificate on request when a client connects and requests a secured page.

Assuming that;

Client is connected to AP controlled by me and ignoring cert validation
AP is running airmon-ng and airbas-ng with DHCP.
OS is Debian on a Rasp Pi, that then forwards to the real WWW

Is it feasible to generate a certificate per request, and if so, are tools available for this, or would the request have to be scripted to sign a cert via OpenSSL, and logging the event.

Cheers

I use mitmproxy (and HoneyProxy a graphical interface to it) at work to do that. Works perfectly.

Relevant part of the documentation about SSL:
http://mitmproxy.org/doc/ssl.html


Can I use Let's Encrypt to verify my signing key? I've made a signing key with GPG and I would like to have it verified since GPG displays a warning whenever a file signed with my key is verified. I've heard of Let's Encrypt but it only talks about HTTPS. Can I use it on my signing key?

GPG and Browsers trust certificates in fundamentally different ways.

How do Browsers do it?

Browsers need a set of trusted root certificates. These either come bundled with the browser, or the browser relies on the root certificates that the OS provides.

When trying to validate a certificate, the browser checks first if the certificate matches what the browser is trying to access (e.g. if a browser tries to access security.stackexchange.com, does the certificate claim to be from security.stackexchange.com?) and then checks who signed that certificate. Then the browser checks that certificate, all the way up to the root. If the root is found in the browser's trust store, the certificate is considered valid.

How does GPG do it?

The above mentioned approach requires trusting certain third parties not to issue bogus certificates. Instead, GPG tries to distribute trust among peers. The way this works is that you generate a key that originally nobody trusts. You then share your key with your peers, and your peers then sign your key. They can choose the following options:

Marginal trust: This option means that you trust that key a little bit, but not necessarily completely. This should be used if you got that key through some means, but can't actually 100% verify that the key is legitimate.
Full trust: You trust that the key belongs to whoever you believe it to belong, and you also trust that the person will make sane signing decisions.
Ultimate trust: This is for your own keys. You will trust everything these keys do, and everything signed by these keys.

How do I fix this weird GPG error?

First of all, your friend needs to verify through some means that the public key they received is actually yours. This can be done through any channel which you think is unlikely to be compromised - most favorably in person.

Then, your friend should sign your key. It doesn't matter what trust they give it, just that they signed it. As a result, your friend's GPG installation will consider the key trustworthy.

Why would you even do such a complicated thing?

GPG is notoriously user-unfriendly, which is likely a reason why it is not widely used outside of enthusiast circles. The core idea behind it, however, is that solid trust established by meeting in person and exchanging keys is very very difficult to subvert. No compromised CA could get you to trust a key which you did not manually set to trust.

If this is something you are worried about is a different story. If you want to learn more about GPG's trust model, this article gives some good insights.


How do I prevent tampering with form submission data, and changing the details for any account? Although this is something that only employees can use, I'd like to prevent the tampering anyway. I don't like insecure code, and this is hideously insecure.

Here's an example link:

Edit User #' + j.id + '.

I sent this to the client side using jQuery:

$.ajax({
    url: "Test.aspx/RemoveUsernameByID",
    type: "POST",
    data: 1,
    beforeSend: function (before) { /* do stuff */ },
    success: function (success) { /* do stuff */ },
    error: function (error) { /* do stuff */ }
});

...and make sure to use SqlCommand.Parameters.Add() to avoid bad stuff:

    [WebMethod]
    public static void RemoveUsernameByID(int derp)
    {
        string ConnectionString = "Data Source=herp;Initial Catalog=derp;Integrated Security=True";
        string QueryString = @"DELETE FROM [Herp] where [uid] = @derp";

        using (SqlConnection con = new SqlConnection(ConnectionString))
        using (SqlCommand cmd = new SqlCommand(QueryString, con))
        {
            con.Open();
            cmd.Parameters.Add("@derp", SqlDbType.Int).Value = derp;
            cmd.ExecuteNonQuery();
        }
    }

Now, as you can see, this is hilariously bad. I am able to tamper with the id in data: 1, and send back any number to the web server to remove any user I want, by their ID. When using this kind of code, I can make myself an administrator, delete any user I want, gather information that I shouldn't be able to, etc.

I've thought about requesting and sending back a bunch of extra information, such as the user's first and last names, or a unique guid, but all someone has to do is sniff this information -- which I've just done! -- and collect it so they can keep doing whatever they want.

What should I do?

This seems more like a Direct Object Reference vulnerability than a SQL Injection vulnerability.

The proper way to secure this would be to check that the current session has permissions to perform the requested action on the server side.  The details of how this would be down depends on how you have implemented authorization in your application, but reading the prevention section of the link I provided should be a good start.


Store credit card numbers in password manager? I pay various things online with my credit card. In order to save the time of taking out my wallet and typing the number to the field, I have two options:

Store the credit card number with the service
Store the credit card number in my password manager

First is bad if a service gets compromised. The second is bad if my machine should be compromised, but then I have larger problems than just the credit card.

I am curious about the following: If I decide not to let stores save my credit card information but instead store it in my password manager, how does liability change? I presume that the first option is just fine with the credit card issuer since that is common practise. But what about the second one? I think that it would be more secure, but does the company see it the same?

I will also contact the company but I am not confident that I will get a straight answer, especially since they block my password manager in their online banking and advise to not store passwords on the computer at all.

IANAL but generally speaking the cardholder is theoretically slightly more at risk using a password manager.

There are several distinct relationships involved.

Merchants who accept and store cards are accountable to their acquiring banks to do so in PCI-compliant ways. If they suffer a breach, they may be liable for the fraud conducted as a result of the breach.

Consumers using cards do so under the terms of cardholder agreements with their issuing banks, which have language that dictates that consumers have to keep the card numbers secret and safe.

Password managers are explicit in disavowing responsibility for the secrecy or custody of any data they store, and have no relationships with issuers or banks.

In theory, if a password manager's systems are breached, consumers using those systems could be found to have inappropriately shared what they were to have kept secret.


How can AWS API Gateway be used to rapidly rotate credentials in this fashion? Reading through this article, I hit a little wall of understanding. The author states:

  This is because my laptop doesn’t have the secret weapon. Once you get
  this up and running on an EC2 instance, these temporary security
  credentials will be automatically retrieved from the instance
  metadata. If the concept of temporary credentials is new to you,
  here’s an excerpt from the documentation (emphasis mine)

I don't understand what he means by these temporarily security credentials will be automatically retrieved from the instance metadata. The argument is that there are temporary credentials being sent to authenticate the application's access to a given secret. He shows a demo script which doesn't send any credentials at all, so I'm not understanding how the demo application actually authenticates to the API Gateway in this model?

import re
import urlparse

# To install the required packages run:
# pip install requests boto3 aws-requests-auth
import requests
from aws_requests_auth.aws_auth import AWSRequestsAuth
from aws_requests_auth import boto_utils

# We got this URL from our provisioned stack's output. This should be passed as a configuration variable,
# but since there's no secrets in there, you could hard-code this
GITHUB_PROXY_URL = 'https://w974f1rs6e.execute-api.us-east-1.amazonaws.com/dev/repos/PokaInc/test-github-api/issues'

def get_aws_auth(url):
    # These next variables are needed for the signing process
    api_gateway_netloc = urlparse.urlparse(url).netloc
    api_gateway_region = re.match(
        r"[a-z0-9]+\.execute-api\.(.+)\.amazonaws\.com",
        api_gateway_netloc
    ).group(1)

    return AWSRequestsAuth(
        aws_host=api_gateway_netloc,
        aws_region=api_gateway_region,
        aws_service='execute-api',
        # This is how we query the temporary credentials of the EC2 instance, as simple as that
        **boto_utils.get_credentials()
    )

list_issues_response = requests.get(
    url=GITHUB_PROXY_URL,
    auth=get_aws_auth(GITHUB_PROXY_URL)
)

print list_issues_response.json()

As shown in the script, there is no authentication other than the script querying a proxy URL.

This is an interesting post, but on your specific question though, the answer is rather complicated (as all of AWS is).

Firstly it's important to understand that nearly every service in AWS is accessible via a authenticated REST API calls. These calls are made by your SDK (e.g. boto3 for python) which provides high level abstraction for your code.

So first let’s delve into how your AWS SDK gets the necessary credentials to authenticate itself to AWS. If you write a bit of code to access a file in S3 for example, your code needs to call the get-object method on the S3 API, and in order to do this, you'll need to sign that request with a key/token belonging to a IAM role that has the privileges to do so.

Fortunately AWS provide a very nice SDK to make this call for you, and all you have to do is supply it with credentials, which it will then use to automatically sign the request for you. The SDK looks for these credentials in 3 different places.

A specific environment variable
In a file located at ~/.aws/credentials
The metadata service

Once the SDK locates the credentials it will sign the request and you’ll be able to get the file from S3.

Most people understand files and environment variables, but trip up at the metadata service ... like what is that?! I didn’t even know it existed until I read the capitalone breach. This service exists on EC2 instances.

When you spin up an EC2 with an assigned IAM role, the instance comes with a metadata service that the SDK can request credentials from. The difference is that it uses STS tokens rather than Long-lived API keys. The end effect is still the same, as the SDK abstracts this complexity from your code. But in the background, your SDK continually requests tokens from the service, and use those tokens to sign the outgoing requests to AWS APIs.

The metadata service exist on a private IP on the EC2 instance (169.x.x.x), hence is accessible only inside the instance.

So what the author suggested was using an EC2 with a script that uses the metadata service to gain access to the API Gateway. That way the script will only use temporary tokens from STS rather than any Long-lived credentials like manually generated api keys. He could not do it on his local machine -- because it didn't have the metadata service.


Suspicious SSH connection this is the situation:

vps with debian 8x32 virgin (new template of the provider's repository);
exotic "user" and strong "password" ;
30 seconds later: command (apt-get update);
30 seconds later: command (netstat);
netstat show :

1 x tcp established sshd connection (my remote ssh client);
1 x tcp sshd connection ESTABLISHED (Chinese ip) (small heart attack);

30 seconds later: command (cat /var/log.auth/);
log contains:
only my remote connection "Accepted";
several attempts to connect invalid (ssh brute force);
30 seconds later:
installed fail2ban for ssh and 4 more services;
configured permanent ban (value -1);
populated hosts.deny with some ip that are attacking;
2 days later: * log revision var / log / auth * | grep [Accepted, invalid, refused, etc];

Everything indicates that no attack has been successful;
The ips hosts.deny are ejected perfectly;
Fail2ban works perfectly;
The attacks by only ip have diminished;
Now the logs only show attacks by only ip and not 200 attacks by ip;
All the "Accepted" connections of the logs are correct (only I with my remote client have been successful in connecting, apparently);

I know the first thing is to deactivate root, passwords, etc. and use public key and other things, but my question refers to the "ESTABLISHED" status of an SSH connection shown by netstat, that is:

Is it possible that a result of netstat ESTABLISHED has been assumed but has not been produced?
Does a result of ESTABLISHED nestat definitely and definitely indicate that the machine has been compromised?
Is it possible that the attacker is playing with modified SYN or SYN-ACK to simulate a fake STABLISHED connection?

Extra: I have seen ESTABLISHED connections 4 times just after being banned permanently by fail2ban and after 2 seconds re-firing netstat and seeing how nonexion vanished like a ninja;

Thanks in advance.

An "ESTABLISHED" connection seen in the output of a netstat command reffers only to the TCP connection. If the port was accepting connections from any remote IP, anybody could stablish a TCP session, where the SSH daemon would ask for login and password, but it does not mean a SSH session is stablished.

You could easily try it yourself: login to your machine via SSH and then, from your local PC use telnet, netcat, socat or any other similar tool open a TCP session to your remote machine on port 22. Then in your logged in session, get the output from the netstat: you will see 2 connections from your local PC as stablished, the one with a SSH session and the pure TCP connection from the telnet.

Search into /var/log/auth.log for SSH sessions. Try looking for "session opened", which should only correspond to your connections.

Also, I would recommend doing a few extra configuration steps on your VPS: first, if your local PC has a fixed IP address and you only plan to connect to the VPS from that PC, restrict via iptables to allow connections only from that IP (NOTE: doing it wrong could lock yourself out of your VPS, caution needed). If it is not fixed or you need to connect from other sources, that option is out of the list. Second: to reduce bruteforce (fail2ban is nice, but it relies on logged events to work, so you will always have some attempts from new sources), I would change the SSH port from 22 to something else.


Password entropy varies between different checks I'm massively under-informed when it comes to in-depth security, however my understanding was that password entropy should be somewhat similar between different algorithms.

I gave a couple of passwords entropy checks, and the algorithms gave me massively varying results.

Is this to be expected, and is there a reliable/standard check for password entropy?

Attempting to add to the other Connor's answer:

Something important to keep in mind is that entropy of course is, in essence, "the amount of randomness" in the password.  Therefore, part of why different entropy checkers will disagree is because the entropy is a measure of how the password was generated, not what the password contains.  An extreme example is usually the best way to show what I mean.  Imagine that my password was frphevgl.fgnpxrkpunatr.pbzPbabeZnapbar.

An entropy checker will probably rate that with a high amount of entropy because it contains no words and is long.  It doesn't contain numbers, but taking a simple calculation (like what Connor outlined in his answer, and what most entropy calculators do), you might guess an entropy of 216 bits of entropy - far more than a typical password needs these days (38 characters with a mix of upper and lower case gives 52^38 ≈ 2^216).

However, looking at that, someone might suspect that my password isn't really random at all and might realize that it is just the rot13 transformation of site name + my name.  Therefore the reality is that there is no entropy in my password at all, and anyone who knows how I generate my passwords will know what my password is to every site I log in as.

This is an extreme example but I hope it gets the point across.  Entropy is determined not by what the password looks like but by how it is generated.  If you use some rules to generate a password for each site then your passwords might not have any entropy at all, which means that anyone who knows your rules knows your passwords.  If you use lots of randomness then you have a high entropy password and it is secure even if someone knows how you make your passwords.

Entropy calculators make assumptions about how the passwords were generated, and therefore they can both disagree with eachother and also be wildly wrong.  Also, XKCD is always applicable when it comes to these sorts of things.


security of AES where attacker can ask secure code to decrypt arbitrary cypher-text A service or library provides a function decrypt( user_id, cypher_text) and gives back plain text. Internally to the function it loads an AES key from a secure vault, decrypts the cypher_text, and returns the plain text. If an attacker gets access to this function alone, but doesn’t know any valid cyphertext, can they perform an attack to recover the AES key for a particular user_id?

To be clear when I say “the attacker doesn’t know any valid cyphertext” I mean it not only doesn’t have access to a matching encryption function but also that the attacker doesn’t have access to any cypher text that has been encrypted with the key. So the attacker can only feed in some specially crafted series of attacking cyphertext and inspect the decryption results to try to deduce the key.

I have looked for the name of such an attack and haven’t been able to find it. In this case the attacker cannot use a “known plaintext” attack as they don’t have access to a function that encrypts with the AES key. I would describe the scenario above as a “crafted cyphertext attack on a decrypt function”. So my question is whether AES is secure against anything but a brute force attack in such a scenario.

Note: As per the accepted answer this is a Chosen Ciphertext Attack (CCA) and certain versions of AES are okay and others are not. “Table 1: Algorithm Summary Table” at Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API describes in the right column which are “ not CCA secure”.

This sounds to me like a chosen ciphertext attack. The raw AES block cipher itself is secure against it. Any cipher you would see used in a modern setting is secure against it.

Some AES implementations you would actually see in the wild are not secure against sidechannel attacks, meaning information about the computation which is not part of the function signature (not the cleartext of a submitted ciphertext). The length of time it took to compute is the most famous, and might be available to a remote network attacker. Contention over caches and execution ports is visible to code running on the same hardware but in another process or VM, and is an attack on shared hardware, possibly in a cloud environment. Measuring accustic noise from electric components might be an attack on hardware in the same room. Actually measuring electromagnetic emanations from the hardware is an attack on smart cards and the like.

The problem is that you never just use the raw AES block cipher. You need to encrypt messages longer than a single block, and you need to protect against malleability. MAC-then-Encrypt AES-CBC turned out to be so hard to implement correctly that fixing all TLS implementations deployed in the wild is now considered impossible, TLS 1.3 dropped those cipher suites and the plan for TLS use in the wild is to just age out all those bad implementations. Anybody not using AEAD in any modern design is rightfully ridiculed.

So, for example, unauthenticated AES-CBC with a padding oracle is trivially breakable, it's an exercise given to non-cryptography people to teach them that cryptography is subtle.

More in-depth information about block cipher security is on cryptography.SE. On security.SE, we'll just tell you how to avoid problems without becoming a cryptographer.

Use a modern AEAD like EAX or GCM, or at least use HMAC with Encrypt-then-MAC and corresponding MAC-then-Decrypt (and make sure the MAC covers the IV if you use CBC, though you should use CTR because it's faster). This way, you never expose crafted ciphertext to an AES circuit that has your key, and don't need to worry about it. Or use ChaCha20Poly1305, and then you don't need to worry about an insecure AES implementation (only hardware AES and bitslicing are secure, all table driven AES implementations are not secure. bitslicing is slow, so almost all AES on hardware that does not contain dedicated AES circuits is insecure. That's why ChaCha was invented).

The really correct thing to do is to not roll your own crypto and use a high level library that has a misuse resistant API like Google Tink or libsodium, etc.


Is this a "valid" security policy item? I'm reading a security policy, which seems to be a system security policy and there is an item that requires the system to implement a specific  standard, something like "Implement the standard XYZ". Standard XYZ specifies a set of default protections that must be implemented.

My question is, shouldn't this be only a part of the requirements for the system?

It makes sense to also put this in the system security policy?

I've read the Security Engineering framework from NIST, a CISSP All-in-one book and many websites, but I wasn't able to come to a conclusion.

It's subjective opinion and depends on the purpose of the policy, who the policy controls and who reads it. If it helps, think about the information security policy like the HR Expenses Policy, or the Anti-Bribery Policy.  I have seen specifics in the expenses policy regarding the mileage rate and general statements about submitting in time.  Infosec policies can be regarded as similar.

Generally, infosec policies are either end user policies, eg don't use USB, or IT department policies, eg all end points must have USB disabled.  Then there are baselines and standards: All end points must have End Point Protector X installed.  Then procedures: install X version Y from location Z.  Sometimes you want to mix them up and sometimes you don't.

It depends on who you are writing your policy for.  Some policies are designed to be read by third parties to get through the compliance hurdle.  Where companies are audited by independent auditors such as for ISO 27001 or where a company has, say, regulated clients then the auditors will look at the policy and look for edge cases where the company does not comply.  In those policies, the author may decide not to write "version X is needed" but rather "use the latest version if it is available and possible to install". Or they may want to unambiguously tell users "your passphrase must be > X characters".

Policies are often written to be seldom updated.  Perhaps an annual refresh.  For some regulated industries there can be a huge inertia to changing the policy, but less for the baseline.  So the policy says "implement the baseline" and then the baseline says "configure X with Y".  The majority of policies will, I suspect, be written this way.  I don't have any peer reviewed data to support that assertion, but most policies that I review tend towards the general rather than the specific but then will call out specifics if the business dictates. For example a policy might say "all websites must use TLS" but a policy for a company that has to be PCI-DSS compliant might say "all websites must use TLS 1.2 or better" (or whatever the standard is now ... that's the problem): the policy might even be utterly generic "all websites must have appropriate security controls in place as determined by a risk assessment".  Where policies are used as the lever to control the business then this could well be the case.

As a rule of thumb, when deciding what level of detail to put into your policy:

Consider the audience
Consider if the policy is there to merely get through compliance
Consider that an organisation may get audited against policy and non-compliance against your own policy is generally regarded as a Bad Thing
Consider if anyone will actually read the policy
Consider if a baseline configuration baked into the devops process is a better place for configuration
Consider if you need to have a some specifics, particularly if there is a minimum acceptable baseline


ECDSA vs ECDH vs Ed25519 vs Curve25519 Among the ECC algorithms available in openSSH (ECDH, ECDSA, Ed25519, Curve25519), which offers the best level of security, and (ideally) why?

In SSH, two algorithms are used: a key exchange algorithm (Diffie-Hellman or the elliptic-curve variant called ECDH) and a signature algorithm. The key exchange yields the secret key which will be used to encrypt data for that session. The signature is so that the client can make sure that it talks to the right server (another signature, computed by the client, may be used if the server enforces key-based client authentication).

ECDH uses a curve; most software use the standard NIST curve P-256. Curve25519 is another curve, whose "sales pitch" is that it is faster, not stronger, than P-256. The performance difference is very small in human terms: we are talking about less than a millisecond worth of computations on a small PC, and this happens only once per SSH session. You will not notice it. Neither curve can be said to be "stronger" than the other, not practically (they are both quite far in the "cannot break it" realm) nor academically (both are at the "128-bit security level").

Even when ECDH is used for the key exchange, most SSH servers and clients will use DSA or RSA keys for the signatures. If you want a signature algorithm based on elliptic curves, then that's ECDSA or Ed25519; for some technical reasons due to the precise definition of the curve equation, that's ECDSA for P-256, Ed25519 for Curve25519. There again, neither is stronger than the other, and speed difference is way too small to be detected by a human user.
However most browsers (including Firefox and Chrome) do not support ECDH any more (dh too).

Using P-256 should yield better interoperability right now, because Ed25519 is much newer and not as widespread. But, for a given server that you configure, and that you want to access from your own machines, interoperability does not matter much: you control both client and server software.

So, basically, the choice is down to aesthetics, i.e. completely up to you, with no rational reason. Security issues won't be caused by that choice anyway; the cryptographic algorithms are the strongest part of your whole system, not the weakest.


Alternative approaches to using DMZ for securing communication to and from external web server outside firewall I am a software developer with little network security knowledge and almost no knowledge of the current network architecture for the environment I work in. If I had any, I still would not want to divulge any information as such could be a security risk. Currently, company policy prevents any server communication outside of our network. As needs are changing, I am looking for a way to relay to management that a safe, reliable, secure alternative approach exists to allow an external web server to communicate with an internal server and vice versa.

I guess the route of having a company server in the DMZ was to avoid the problems of not having remote access and not being governed by the company network team. The desired approach is to possibly use a third-party service such as through a cloud service and thus gain control over our own deployments.

An alternative approach that was suggested by a peer to having a server in the DMZ was to only permit communication with HTTP protocol, block all ports but 80 (not sure if on server and/or firewall), and only allow GET and POST verbs.

Please enlighten me with the possibilities, concerns, side effects, suggestions, and alternative approaches of achieving the ability to allow an external server to communicate internally and vice versa that do not involve a DMZ. Please do not use a link to a 500 page PDF as your answer unless it is provided as a reference with some good detail.

Thanks in advance!

The traditional answer is a three-tier architecture: web, app, and data.  Your web layer is isolated out front, and can only talk to the app server with limited methods (e.g., only a small number of RPC-ish calls available).  The app server then talks to the data(base) layer, and of course you can do whatever with ACLs or stored procedures to make that more secure.  For security purposes, a three-tier architecture is a good solution when done right.

You're peer's suggestion about only allowing port 80 is sort of an assumed minimum.  And whitelisting the verbs is fine, but realize that the majority of attacks you'll face operate above that layer and will route quite happily over GET/POST.  Which leads into the modern answer: Intrusion Prevention Systems that'll watch all the traffic going by, detect malicious patterns, and act to interdict them.

The traditional answer and the modern answer all lead up to the real answer: you can't set [an external web server] up that's as safe, reliable, and secure as not having one in the first place.  Whatever you do will increase your risk by some margin.  How you do it will change how big that margin of risk is.  Whether you go with a three-tier architecture, IDS/IPS, log monitoring and alerting, etc...  You and your management decide how to mitigate the risk, and get it to an acceptable level.

And unfortunately, learning how to safely mitigate the risk means digging through 500 page PDFs to learn the tricks.  A hat for a cat, or a cat for a hat, but nothing for nothing.


what scanning tools are unlikely to set off network IDS? What network scanning tools have a stealth option to avoid detection?

As with most things - it isn't about the tool, it is how you use it.
Take nmap for example.
Beginners to the tool or script kiddies might run scan using the default option.

nmap 192.168.1.0/24

The default behavior for nmap without specifying any addition flags would be to perform a syn scan, so the above query would be equal to.

nmap -sS 192.168.1.0/24

Syn scans are reasonably stealthy. However, most modern firewalls/IDS should be able to detect syn packets as it is a very common scan technique.
Slightly better but still inexperienced users might perform even noiser scans using nmap.

nmap -sV 192.168.1.0/24
nmap -A 192.168.1.0/24

An nmap scan triggered with those two scan flags are VERY noisy. In addition to sending a variety of packet types and grabbing banner information, nmap will use the nmap scripting engine to perform additional tasks such as bruteforcing the SNMP community string if applicable. Such scans will be easily detected.
More experienced users can perform more stealthy scan types by specifying certain flags. nmap is a very powerful tool as it allows you to set different flags in a TCP packet to evade firewall rules. ACK & FIN are two very commonly used techniques to evade firewalls.
Other advanced techniques like idle scan can also be performed using nmap. It is a very versatile network scanner that can be very silent in the hands of an advanced user.
Some tips
Do not perform syn scans or version scans on entire subnets unless needed. It is slow and noisy. Instead, use the ping scan option to find out which hosts are active on a subnet.

nmap -sn 192.168.1.0/24

This option would return a list of active host IP and MAC addresses in the subnet.
Once you have obtained a list of active hosts, selectively scan hosts which you think are interesting. For example, the IP address 192.168.1.1 seems interesting to me, I might want to know more about it. Perform a syn scan.

nmap -sS 192.168.1.1

By default, nmap scans for the most popular thousand or so ports according to a list compiled by the author. This is good enough for most purposes. However, there might be some scenarios where you might want to specify specific ports. You can do that using the -p flag.

nmap -sS -p 80 192.168.1.0/24

This scan would send syn packets to the entire subnet, searching for active IP addresses with port 80 open. This is a useful scan for determining which host might have an active HTTP server.

nmap -sV 192.168.1.1

The -sV flag specifies the version scan option. This option instructs nmap to send a wide variety of packets to the hosts and scanning the headers of the packets returned to check for the exact version of a service the host is running.
This is a very powerful but noisy version. Use with caution.

nmap -A 192.168.1.1

The -A flag instructs nmap to use an aggressive scan. This is one step up from the version scan and utilizes the nmap scripting engine. This is very noisy.
nmap is a highly powerful tool. If you want to learn more, i highly suggest you pick up the book written by its author.


How secure is to authorize a website to "trust your device"? A bank has a form of 2FA where, after you put in your username and password, they send a code via SMS  to your mobile phone and you have to put that too.
On the screen asking for the SMS code, there is an option to "trust this device", meaning that they won't ask for this SMS code (but still ask for username and password) on "my device".

How do the website knows that the one connecting is "my device" and so it doesn't have to send the OTP but let me pass through? I suspect it is done by cookies, but I don't know for sure.

Can someone "forge" a request to let it appear it comes from my device when in reality it doesn't?

How I am exposed in case someone steal my PC?

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").


How can I generate some public and private keys on both sides with low overhead? We have an Authority Center (CA) generating some public and private keys for each client (more than one pair for each client). One method for sending keys to client is sharing a secret key between CA and client, and then sending key pairs and certificates by symmetric encryption method (with secret key). But overhead will be high, so i need an efficient method with low message overhead and time for key pairs transmission. How can i do it?
is there any way to both sides share a secret key and then generates key pairs using it, without transmitting key pairs, (a way that confirm the key pairs are reliable for CA)?

a way is that public keys are hashed to a common value. is it possible for clients to generates such public keys? but i think it takes a lot of time.

it's very important for me, please help me.

is there any way to both sides share a secret key and then generates key pairs using it

You can derive further keys from an initial shared key, there are various key derivation mechanisms that would allow you to do this, but you still have the problem of distributing the initial key. Anyone who intercepts this key could replicate the derivation process and derive the same subsequent keys, so you still need to securely transfer this initial key and you have the same problem you started with. This applies to your suggested solution as well; wrapping the keys with a shared secret is a sound idea but you still need a way of securely sharing that secret.

Key distribution is probably the single most difficult part of implementing a cryptographic system. Distributing symmetric/secret keys, as would be needed in the solution you mention, is especially difficult, which is why they are often negotiated wrapped under asymmetric keys, such as is the case for SSL and similar, as the encryption is done using the public half of the receivers key which is not confidential, but you then still have the issue of distributing and verifying the public keys you are using to encrypt the symmetric keys, which is often solved by implementing an entire PKI (public key infrastructure) system, which includes CAs (certificate authorities).

You do mention using a CA, but what you are describing does not seem to be the manner in which a CA usually operates, which would usually involve the client generating their public/private key pair then sending the public half to the CA to be signed and receiving a certificate in return. These certificates can be verified by other clients due to them including the root CA certificate in their store of trusted root certificates. You've described in the comments why you're doing it differently but I'm still not sure I really follow your reasoning...

It also surprises me that the overhead of a simple symmetric encryption is too high for you. Have you actually tested the performance of this and deemed the performance hit to be unacceptable? This smells a little like premature optimisation to me, as symmetric encryption is not particularly computationally expensive (unlike asymmetric, which is why asymmetric is usually only used to negotiate a shared symmetric key which is used for any subsequent data encryption). If the overhead of a single symmetric key wrapping is too intensive then I would be surprised if you have the computational power to use encryption at all, and possibly you should rethink your approach to what it is you are attempting to do.


Security risk stemming from data passed in $_GET superglobal This is a short but general question. I am relatively new to programming in general. My site, which is predominately written in PHP, will be launched soon and is undergoing some security tightening. This started with converting the whole thing to PDO with prepared statements (from what was a MySQL set up) to making sessions more secure.

My issue is this: I make quite a lot of use of the $_GET superglobal to pass user IDs around and thread IDs in the Q/A section. If a member clicks on another member's pic, they are sent to that user's profile page invariably using a $_GET['id'] to send the info - usual newbie type stuff.

I am concerned that this may pose a security risk as the members' ID numbers are essentially visible throughout the site.

I am not sure that creating forms with hidden $_POST variables is the answer. I have searched for answers on this, without success regarding this exact question.

I know this is not code, but I would appreciate some steerage on whether this actually does represent a problem, and if so, how.

Seems that my comment did not make it here, so i'll post it as an answer:

No, it is not a serious security concern. If your site has for example a blind sql injection vulnerability, this would make it easier to attack a specific user.
It probably also makes it a lot easier to scrape your website for user profiles, if that is a concern of yours.
But other than that, I cannot think of a way to attack this.

But if you are still concerned:
No, hidden post variables are not the answer.
Instead, do not pass the ids, but pass slugs of usernames/postnames/etc instead (the slugs should be sanitized, so that they do only contain valid url characters). This is also more user and seo friendly.

But do make sure not to output any user supplied data directly to the enduser. You have to sanitize it first to prevent xss attacks (and it does count as user supplied even when it comes from the database - if the data in the database is user supplied).


How long does it take for a gpg key revoke certificate to propagate to all public key servers? I recently created a new gpg key just for the sake of learning the basics of public key encryption.  Now, I'd like to revoke that test key so that I can go on using a more "permanent" key that is associated with my personal email account.  Using the GPG Keychain application on Mac OS 10.15.*, I was able to revoke the key, and upload the revoke certificate to what they refer to as the "public key server".

However, when I attempt to search for my revoked key, I'm still able to find my public key indexed by my test email address.  I've tested this on the OpenPGP Keyserver, the MIT PGP Key Server, and with the search function built into the GPG Keychain application.  In the GPG Keychain, I am provided with this warning message when I try to search for the revoked key:

  The following keys were found.  Note that the search results come from the old sks key servers and are unverified:

My question is this, how long will it take for my revoke certificate to propagate to all the public key servers, so that my public key is no longer searchable in any way?  Is it just a waiting game for the "old" key servers to synchronize with the "new" ones?  Will I always be able to search out the public key by email?  If so, what happens when the key reaches it's hard expiration date?

public key is no longer searchable in any way?

Won't happen. Your key will still be listed indefinitely, it will just be expired as of the date you revoked it.

  waiting game for the "old" key servers to synchronize with the "new" ones?

I recently searched 6-8 keyservers and got 6-8 different lists of available keys including some old ones I had forgotten about.

In sum: GPG keys once uploaded persistent indefinitely, may or may not propagate to other keyservers, and are nearly impossible to remove. They can only be modified by revocation which really only sets them to expired.


How to evaluate a wireless network risk level? When travelling everyone has to use structural wireless networks (managed by airports, hotels, museums, restaurants…).

Some of these only open (80|443)/tcp/ip once you have
provided an E-mail or simply put a
check mark in front of an I agree button
at the end of one page of conditions of use.

But before this web ports opening,
a basic tcpdump showed me a terrific amount
of traffic (for example waiting in many
international airports):
ARP, STP, netbios, VNC, ARD…

Beside tcpdump is there any way for
a standard user or for a network aware one
to evaluate how dirty water is any free wireless network?

This question stands both for before
activating the web ports opening, and after
this opening.

The only sensible way to approach this problem is to assume that any public wireless network you connect to has hostile elements connected to it.  You should ensure that all traffic is encrypted either using SSL for specific sites, or using a VPN to encapsulate all traffic over the local wireless network.

Many potential risks are passive (e.g. sniffing attacks) or not easy to detect, so it isn't likely a sensible approach to attempt to assess trustworthyness on a network by network basis.


Security element that relate to breaking protocol I am working on evaluating an unsecure protocol. I am trying to categorize the vulnerabilites according to some commonly accepted security elements like the ones specified in the CIA triad or the Parkerian hexad.

There are many vulnerabilites that i can relate to the Parkerian hexad, for example participants can fake their id which would relate to the authenticity element of the Parkerian hexad.

Another vulnerability is that the rules of the protocol can easily be broken, for example participants that follow the protocol aims to form groups and one rule is that participant should never be in more than one group at any given time. The rule is broken if malicious participants send join-requests to different groups.

Basically, i am looking for some security element like confidentiality in the CIA triad or authenticity in the Parkerian hexad that would relate to "breaking of protocol-rules". Are there any security element, for example in the parkerian hexad or other that relates to "breaking of protocol-rules"?

Parkerian hexad

Cia triad

The concepts that affect information in CIA and the Parkerian hexad cannot be mapped to technical controls of a protocol at the protocol level. A protocol's controls are meant to enforce security elements.

What you can do is to relate the vulnerability to the effect on information. In your scenario, how is information at risk? Why is being a member of different groups an information security risk?

Breaking of the intent of a protocol's design is not inherently a security risk. There is just simply a violation of design intent.


HashCat on VeraCrypt non-system drive With VeraCrypt, one can fully encrypt a non-system drive. I'm wondering if there's a way to run hashcat against such a drive. (Bonus points for a Windows solution.)

The procedure should be the same as for TrueCrypt, as documented in the hashcat FAQ.

You'll need to extract the first 512 bytes of the target volume, save them as a file, and use that file as the hashcat target. (Boot drives require pulling the 512 bytes starting later in the drive, but non-boot drives can be treated like file-level containers, pulling the first 512 bytes.)

On Windows, you can use dd for windows to do so. Use dd --list to determine the drive ID for the drive, and then:

dd if=\\.\Volume{volume-guid} of=c:\temp\veracrypt-target.img bs=512 count=1

and:

hashcat -a 3 -w 3 -m 137xx c:\temp\veracrypt-target.img

(with the hashcat command modified to match your attack type).


What methods are there for using an encrypted database to perform logging that is legally and forensically trustworthy? I am researching logging in a way that it could be used legally and also forensically trustworthy.  I have seen discussions about remote logging, hash chaining, timestamp chaining, write-once media.  My question is, Is it a viable solution to use an encrypted database, with similar techniques?  If so, are there any points that make this more attractive an option security wise?

Not that I can see. An encrypted database is (partially) protected against outside attackers. For your logs to be forensically acceptable, they need to be protected from modification by you and your system administrators who have full authorised access, and since you'll have the keys to your encrypted database, the encryption doesn't help with that.


Does TLS fall back to unauthenticated key exchange if the CA is not known to the client? My lecturer said that if the server sends a public key certificate (RSA) signed by a Certificate Authority that the client does not know about (i.e. the client doesn't have a master certificate for the root CA in that chain), then the key exchange protocol falls back to some form of unauthenticated Diffie-Hellman (e.g. ECDHE or DHE). Quoting from the slides:

If the server does not have a certificate signed by an authority that the client has a master certificate for then an alternative has to be used.
The most common is to use Diffie-Hellman. This is then vulnerable to a man in the middle attack.

It seems strange to me that, if the client doesn't recognize the CA, it just skips any attempt at authentication and goes ahead with the connection anyway.
So I asked him whether this is something that happens automatically, i.e. whether this (ClientHello -> ServerHello -> client doesn't recognize CA, asks server to fall back to DH) happens automatically within a single TCP/TLS connection. He said, essentially, yes, that the client can then decide whether to fall back to DH or to abort the connection, and in the first case, there is some additional dialogue between client and server to make that happen.
Is there any TLS cypher suite or sub-protocol that entails this behaviour?
Or maybe I misunderstood: maybe this does happen, but not at the TLS level but rather at the application level? E.g. a browser tries to access a web page with an authenticated TLS ciphersuite, the connection fails because the client doesn't recognize the CA, so the browser asks the user whether they want to go ahead in "unsafe" mode (i.e. with some unauthenticated TLS cipher suite), and if the user accepts a new connection is established but this time using another TLS ciphersuite.

I am being generous and I assume your lecturer is merely extremely out of date and they meant anonymous TLS cipher suites.
In the 90s, a TLS client might have sent a ClientHello which lists cipher suites in preference order and included something like "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DH_anon_WITH_3DES_EDE_CBC_SHA". The TLS server might have looked at it and decided that since it doesn't have an RSA certificate (because it has a DSA certificate or a static DH certificate or no certificate at all) it can't use the first option, so it's going to use the second option, and they would have used unauthenticated TLS.
They may as well also use TLS_NULL_WITH_NULL_NULL (yes, no key exchange, no authentication, no encryption and no MAC).
In the real world, those cipher suites are not allowed. Decent TLS 1.2 implementations simply don't support them. TLS 1.3 doesn't include such things even in theory, AFAIK.
Additionally, there has never existed a mechanism by which a TLS client can look at the certificate chain offered by the server and change its mind and ask for a different cipher suite in the same session. It's too late, the cipher suite has been chosen already.
A TLS client can try some values in ClientHello, look at the response from the server, decide it doesn't like it, close the connection and try again with different values in ClientHello. This might be required to deal with server bugs related to negotiation, in particular the famous TLS version intolerance. SCSV has been invented to prevent downgrade attacks on such clients.
Almost universally, the TLS client does not tell the TLS server which CAs the client trusts. The "TrustedAuthorities" extension exists (and a TLS 1.3 replacement), but I've never seen it used. If it's used, it is used only by small embedded devices (same as Maximum Fragment Length).
In common use, a TLS client tells the server:

The supported TLS protocol version.
Optionally, the domain name, using SNI (this is often needed to make HTTPS work)
Optionally, the next protocol (using ALPN), which is needed for
HTTP/2.
Optionally, which kind of digital signature system and which
kind of hash function (TLS 1.3 version) the client is willing to use to verify signatures,
which is an opportunity for the server to choose between RSA and
ECDSA certificate, if it has both types for the domain (or at all,
if selection by domain name is not used). At a time when SHA1 certificates were not allowed in general but still allowed for clients that do not support SHA2, this was done.

A TLS client might try different values of all that (and more) to see if the server sends different certificate chains (or cipher suites). No TLS client I know of performs the fallback retries conditionally on user input. Either it performs retries or it doesn't, based on policy, and at the end it comes back to the user with the best result it was able to get and either shows "secure" indicator or shows an "insecure" indicator or shows a "full page interstitial" (a full page error with a hidden "disregard and continue" button, like this).
Note that the TLS protocol really is meant to work without the client probing different handshake options. For example, consider a server that has a preference for cipher suites in a particular preference order which is ordered in a silly way. A client that offers "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA" will get CBC instead of GCM, even though the server supports GCM. The client might see the choice of CBC and try a different handshake in which it offers only GCM. If it then gets GCM, it might learn that the server is silly and it should craft handshakes for that server in which it does not offer CBC. The TLS protocol authors would like it if people did not have to do this, and so they would prefer if TLS servers always made sensible choices given any particular ClientHello. GREASE was created to try to fix one reason for such fallback retries.
BTW, TLS 1.3 made significant changes, so much that they thought to call it TLS2.0. You should look at the RFC.


Can a hacker hack into port 80? We normally say port 80 is firewall friendly.
But can a hacker just hack into port 80 via TCP or UDP?

Or is Port 80 by default not always open?
It waits for the host to initiate a connection via specific application/service to a host application then the port is opened at that time?
Is a hacker required to fake that specific host application in order to hack into our computer?

A port itself cannot be hacked, rather, it comes down to if the service running on that port contains any vulnerabilities. If you're running a web service on port 80 that contains no known vulnerabilities, your chances of being hacked are low depending on your situation. If you're running a vulnerable service on port 80, you're at risk to be popped by an attacker or botnet.

Port 80 is not open by default on most operating systems, you will need to manually launch a service that utilizes that port. Also, no, an attacker is generally not required to pose as another host in order to compromise your computer externally.


Deserialization Opportunity? I have minimal experience exploiting deserialization vulnerabilities and I am working on and I have identified the following URL endpoint. This is it URL Decoded:

/Account/Register?Count=0&Keys=System.Collections.Generic.Dictionary`2+KeyCollection[System.String,System.Object]&Values=System.Collections.Generic.Dictionary`2+ValueCollection[System.String,System.Object]

I'd appreciate some help explaining if it's exploitable, and if so, how so I can prove impact to the client. Thank you.

This looks more like a bug in the application which is ignored or handled by the server rather than something exploitable.

This code (in c#)

List<string> list = new List<string>();
list.Add("Hello");
list.Add("World");
Console.WriteLine(list.ToString());

Outputs:

System.Collections.Generic.List`1[System.String]

So it would appear that while the developer is expecting to output the contents of the keys and value lists into the url they are in fact just outputting the type of the object. Since it doesn't seem like this features can work in the first place it's difficult to see how it's exploitable, it probably falls more under the information disclosure category than an exploit.


Will webshells forever be a challenge for organizations? The only ways of detecting webshells today are either by using FIM technologies, which are a problem if you start deploying them on "dirty" systems. You literally have to deploy them on clean systems in order to get a baseline of what a good state looks like.

Not only that, but the alternative to FIM technologies is using some signatures or some anomaly detecting systems, which won't always give you a solution (e.g if the attacker modified the code of an existing file as opposed to added his own webshell).

So, until some new technology is created, is this seriously where we stand?
The challenge is there, and attackers today still use webshells as one of their main weapons in the adversary arsenal.

Webshells is an attack payload, not a vulnerability. If you don't have a vulnerability that allowed the attacker to install a webshell in the first place, then you don't really need to worry about webshells.

Webshell detectors may be useful to catch an attack that already happens. But if the attacker already manage to install a webshell, then the attacker are already in too deep for you to trust the machine.

Another use of webshell is for sysadmin using a webshell to administer their machines, these shells must be run over HTTPS and must be authenticated to prevent abuse by attackers. If an attacker manage to get into one of this legitimately installed webshells, then it's a vulnerability in the authentication mechanism surrounding the webshell, not due to the webshell itself.


Safe to utilize "unknown" SSH-server? I've been offered a free Secure Shell at a friends server. However, I was wondering if it might be insecure to join this server from my personal computer at home - may my computer pose any security risks open for attacks from him whilst being connected to his server?

Note that this friend and I barely know each other, thus I cannot be sure that he doesn't have any hidden & bad intentions.

If it's somebody you barely know then they aren't a friend, but an acquaintance. There's an important difference here, I'd trust a friend to offer me a shell in good faith, but with an acquaintance I would not have a high level of trust.

That being said accepting a shell login from someone you don't know that well is a low risk to your system as there are few options there for him to attack you through your ssh client directly. The real risks come from being on the system itself:

You don't know what he's doing. If he's engaging in criminal activity and you are logging into the same system as him you could end up being investigated
Whatever you do on the system is available to him. If you write code or store personal information he could view it, if you use it for browsing he can see your history
Downloads from the system could be used to attack you. This is the direct risk to your system.

How much of a risk this all adds up to be depends on how well you know this person and their reputation, what you plan to do with the offered shell, and what you have of value (are you a target). If you make sure your system and ssh client are all up to date and use good sense you shouldn't run into too many problems.

Just remember to practice good user ethics. this person has offered you something, don't abuse it by doing anything illegal or unethical with it. Also, take care not to mess with his server.


If hashing is one way, why can we decrypt MD5 hashes? I have read some times that hashing is a one way function, that is you can make the hash of a message, but you can't recover the original message from the hash, just check its integrity.

However, if this were true, why can we decrypt MD5 hashes and get the original data?

Hashing is not encryption (it is hashing), so we do not "decrypt" MD5 hashes, since they were not "encrypted" in the first place.

Hashing is one-way, but deterministic: hash twice the same value, and you get twice the same output. So cracking a MD5 hash is about trying potential inputs (passwords) until a match is found. It works well when the input is "a password which a human user came up with" because human users are awfully unimaginative when it comes to choosing passwords.


Could PDF's `/Filespec` type allow for remote file access? I've read the PDF 1.7 spec 7.11.1 (okay, not all the spec, but a part of it), and I've seen that you have what Adobe calls /Filespec type objects.

As far as I get it, this means that a PDF can make a reference to a local file (or even a remote file using URI scheme) when opening the PDF. This would be a pretty neat way of attacking some servers I'm in charge of, because such server accepts user-uploaded PDF, opens them with wkhtml/tcpdf/jasper to make changes in that PDF, and then resend this PDF to the user. So if the user-uploaded PDF contains a file reference to, say, /dev/random, and if that reference is used as the PDF's page content, then it would open up a breach to read arbitrary server's file content?

I would like to test that, but I can't make such PDF exploit: when opening the PDF I've forged on my lab (ie: not server, just a basic PDF reader), then no content is displayed (and PDF is considered broken).

So do you have some example of such PDF with a working file reference (so I can test if PDF processor is vulnerable to it)? Or any reference stating that these /Filespec cannot be used to read arbitrary file's content (so no need to test the PDF processor)?

I'm not sure about the feasibility of what you suspect. A library able to work with pdf files may not need to process such Filespec entry to perform its work (for instance the Filespec -if not an embedded file- could be referring to a font, only used when rendering it). And I suspect any library will not enable reading of external files without explicitly enabling such feature, as it could lead -as you note- to nasty surprises.

However, in case of doubt, and given that these are complex programs dealing with a nin-trivial format, I would apply the precautionary principle and process them in a sandbox/chroot/firejail/docker container, so even if the programs processing the pdf could be directed to open arbitrary files they actually can't open any sensitive file, only the standard files that were included inside the sandbox.


How can I log access and usage of a MySQL database? I am currently looking for an existing implementation method to generate logging of accesses and of usage of a series of MySQL databases by developers (not services) for further auditing. My current estimate is that all traffic would have to go through a proxy that logs everything and transparently forwards it to the target database server. I have tried looking through the logging mechanisms inside MySQL and it doesn't seem to generate the information I need.

Is my assessment correct?

I don't know if this question belongs here (or if I should post a second question) but I have been reading into something called HashiCorp Vault as I've been told that it covers my use case. I don't see how a centralized secret storage system will help me with the generation of logs for auditing.

Does anyone know if this supposed Vault will actually log access or even act as a proxy?

If you are trying to track access to data from your MySQL database for HIPAA and the PCI Data Security Standard then you want MySQL Enterprise Audit plugin and there is also a MariaDB Audit plugin.


Different Diffie–Hellman key per site? I recently put each of my sites through the ssl labs analyzer and now have them all running with an A+ getting perfect scores with every metric except Key Exchange at 90.

As part of this I have globally set my Nginx server to use a dhparams.pem file for ssl_dhparam. My question is whether or not it is fine for all my different sites to use the same dhparams.pem file, or would it be considered better practice for each site to use a different file?

The Diffie Hellman parameters are not secret. In fact they are shared entirely during every key exchange. Reusing them should not be a major issue in general, if they are of good quality and length.

At one time it was reasonably common to use 512 bit parameters. An attack called logjam was discovered whereby data to decode the key exchange could be pre-computed allowing reasonable attacks. This is considered to be impractical for even 1024 bit parameters, so using 2048 or 4096 bit parameters eliminates the possibility of a pre-computation attack on your specific values entirely.


Why is the SHA-1 hash of certificate sent in TLS "Client Certificate URL" extension? According to RFC6066, constrained clients can send certificate URLs instead of full certificates for TLS client authentication:

After negotiation of the use of client certificate URLs has been
successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients MAY send a
"CertificateURL" message in place of a "Certificate" message as
follows (see also Section 2):

     enum {
      individual_certs(0), pkipath(1), (255)
  } CertChainType;

  struct {
      CertChainType type;
      URLAndHash url_and_hash_list<1..2^16-1>;
  } CertificateURL;

  struct {
      opaque url<1..2^16-1>;
      unint8 padding;
      opaque SHA1Hash[20];
  } URLAndHash;

...

The hash corresponding to each URL is the SHA-1 hash of the
certificate or certificate chain (in the case of X.509 certificates,
the DER-encoded certificate or the DER-encoded PkiPath).

...

The server MUST check that the SHA-1 hash of the contents of the
object retrieved from that URL (after decoding any MIME Content-
Transfer-Encoding) matches the given hash.  If any retrieved object
does not have the correct SHA-1 hash, the server MUST abort the
handshake with a bad_certificate_hash_value(114) alert. This alert
is always fatal.

An active attacker can easily modify the URL to point to a certificate (or certificate chain) of their choice & replace the 20 bytes of "SHA1Hash" with the corresponding computed SHA1 hash, and the server will realize the problem only when it tries to verify the "Certificate Verify" message from the client. Also, the server verifies the SHA1 hash only after fetching the contents pointed by the URL, so any generic attack like buffer overflow or SQL injection on the server hosting the URL is also not prevented. Then, why is 20-byte SHA1 hash of URL included with this message?

From my understanding your problem is that an active man in the middle can make a server S access a URL at host U and this URL is specified by the attacker. And the problem with this is not that the attacker might get to the contents behind this URL (he can't) but that just accessing this URL might trigger a bug at the server U.

Thus to make this attack working the following conditions must apply:

There must be a bug in server U which can be triggered just by accessing the specific URL.
The attacker can do an active man in the middle attack.
The attacker is either not willing or not able to access server U directly so it needs to use server S to access this URL.
Server S does implement the feature to get the clients certificate from a URL.
Server S does no filtering which kind of URL's it can access or server U is allowed by this filter.

If all this applies it can be used to attack server U. But in most cases there are far easier ways to make somebody access URL, like accessing the URL directly, including it in some <img src... tag at some web site to be accessed by somebody else or similar.

  Then, why is 20-byte SHA1 hash of URL included with this message?

While I do not find any explicit explanation in the RFC my guess is that it is only to make sure that the server U actually provided the expected content and not something else which makes a bit sense in cases where the client itself has no real control over changes done at server U. This is not to prohibit attacks against server U.

Of course if the content served by U does not contain the expected client certificate it will be noticed during the handshake anyway because the private key used by the client does not match the client certificate. Thus it is questionable if this hash is really helpful or if it is just another useless feature which nevertheless made in in the standard: Remember the TLS heartbeat extension where the server for no real reason had to send the contents of the clients request payload back?


What is the protocol used for authentication/authorization of my internet access using account inside web browser? Our university uses Microtik devices and a 3rd party application to manage our access to web and internet services.
When I open browser in my desktop or connect to a wi-fi access point, it prompt that you should sign in to access network. Like something shown below:

When I click the prompt in mobile phone it shows up a web page and it requests for my account information and after a successful login, I can access Internet.

I want to know what is the name/type of protocol used for this authentication/authorization mechanism which lead to such a pop-up in browser?

You can ignore below part but your answer would be welcome:
Besides I want to know are there any software or configuration which can skip user name/password prompt and authenticate automatically under windows or android or there are no any?

This technique is called a Captive Portal.

There actually is an RFC standard for this since 2015. This RFC extends the DHCP and IPv6 RA protocols to inform the client about the URL of the captive portal as soon as it connects to the network. But this method is not yet very widely used. I am not even sure how widely it is supported by end devices (it would need support from both the operating system and the web browser). The usual procedure is to do it with a HTTP redirect like this:

When you connect to the WiFi network, the router (acting as a DHCP server) gives you an IP address. But that IP address gets marked as "unauthenticated" by the router.
When an "unauthenticated" IP address makes a http or https request to an external website, that request gets intercepted. The router replies with a redirect to the login page. Depending on your browser's security settings, this might generate the "Your connection is not secure" error on HTTPS requests, because the reply doesn't come from the website it is supposed to come from.
When you enter your login credentials, your IP address gets marked as "authenticated" and can now access websites normally.

The "You must log in to the network" below the address bar is a special feature of Firefox called "Captive Portal Detection". It works by requesting the URL http://detectportal.firefox.com/success.txt and comparing the response with the expected one. If the browser receives a redirect or a login form instead, it assumes that the user is blocked by a captive portal.

  Are there any software or configuration which can skip user name/password prompt and authenticate automatically under windows or android

I don't know any, but if you use the same wifi regularly, then you could do it with a little shell script which uses wget to POST your login credentials directly to the captive portal URL. But you would need to write this specifically for each network, because the login URL and the POST fields will be different.


What does a IT Security Pro need to know about .NET Code Access Security (CAS)? Background

In .NET 1.0 through 3.5 administrators could administer the runtime security policy through mscorcfg.  Aparrently many of these security features have been removed in .NET 4.0,. Furthermore there instructions telling me how to launch this security tool but I can't find it anywhere on my Windows 7 laptop.

Question

What does a security pro need to know about Code Access Security (CAS)?
Why have these security features been removed from .NET 4.0?
How do we secure .NET 4.0 apps?
If the security tools for .NET 3.5 and older are actually hidden from administrators, does that mean we are creating security problems for ourselves?  Particularly, if we can't see what's going on for older .NET applications won't that create problems down the road?

What does a security pro need to know about Code Access Security (CAS)?

Honestly I would say not a whole lot; until you need to know about it.

  Why have these security features been removed from .NET 4.0?

Because the security was complicating, leading to questions like this. It was also an incomplete solution since it was only .NET applications that had this functionality. Take for example, that a .NET Executable run over a network share would run in medium trust. Medium trust would prevent access to a lot of functionality, but it was done in the name of security. It however, did have its flaws.

Native EXEs did not behave this way. If someone was going to write a malicious executable, they probably wouldn't opt to do it .NET. A native executable does not behave differently when run over a network share. However, it did stop a very "cheap-and-simple" means of network applications being useful.
Administering it was downright confusing. Between Code Groups, zones, Strong Names, Application Identity, and permission sets, a lot needed to be known for something that didn't provide enough security.
The concept was born before UAC and AppLocker, where people that were Administrators always had administrative permissions. UAC goes much deeper than a .NET application, it's at the operating system level.

  How do we secure .NET 4.0 apps?

Your real goal isn't "to secure .NET apps" but "to secure all apps". AppLocker or SRP are more effective because they apply to any application. .NET, Java, Native, etc.

Additionally, by restricting the user's permission, not the application. Creating a policy application-by-application takes great effort, and even more difficult when you need to start creating exceptions for certain users.

That isn't to say that .NET 4.0 doesn't have a security model at all. .NET 4.0's replacement is Security Transparency, and "hosted" applications like Silverlight, ClickOnce, etc still have CAS-like permission sets applied to them.

Security Transparency relies more on a grant set provided by a sandbox. Take for example, Silverlight. Silverlight will give a different grant-set depending on whether the application is running in-browser (Medium Trust), or out-of-browser, which can have Full Trust. Running out-of-browser takes a users approval to do so, and even then it is restricted by things at the operating system level.

It's up to the developer to know what permission sets he has depending on which sandbox his application is running on. In effect, .NET 4 applications get the same "sandbox" as native applications. Silverlight, ClickOnce, etc get their own sandbox that have greater restrictions.


E-mail can be made to appear like it came from a big organization? I know almost nothing about security. So, please bear with me if the questions sound silly.

Is it possible for a malicious person to make an e-mail appear as if it came from a big company like Google, Apple, Cisco etc ? If yes, what kind of techniques do they use and how to detect these fake e-mails ?

Another thing - I guess that big companies like these must be having different servers to send out official e-mails. Is it possible for someone to create a fake server or add their own server to the company server list and then send malicious e-mails from it ?

Also, could someone silently hijack a company's mail server, send malicious e-mails to a few targets only to avoid detection ?

It sounds like you're asking about email spoofing.  Look here for a good primer on the subject

Email all by itself is not a secure technology, and it is very easy to spoof a sender.  Often times the mail server doesn't need to be hijacked to send email as that person.

People who want to protect their branding need to implement anti spoofing technologies.  Some anti spoofing technologies include SPF records, DKIM signing, and DMARC authentication.

When the sender and the receiver both implement SPF, DKIM and DMARC properly then spoofing risk is greatly reduced.


Shared clipboard on Linux without keylogging, etc. vulnerabilities? X has some serious security problems, not the least of which is that any program using a given display can log keystrokes from any other program on that display. (This can be demonstrated easily using xinput.)

Is there any way to mitigate this within a single X display, without losing essential things like shared clipboard support?

e.g. would it be possible for a window manager to intercept all keystrokes, and pass them on only to the program owning the currently selected window?

Also, is there at least any way to prevent programs from sending sequences of keystrokes to each other? As things are by default on almost all Linux distributions, a compromised program running in my account could send 'rm -rf /\n' to a shell prompt running as root.

I know Linux has mandatory access control frameworks aplenty, but for purposes of spying on a user, those are all AFAIK rendered moot by X having insecure design from day one. What steps can be taken to reduce this hazard?

There are some work being done in this direction. Some links/ideas that could help you:

The OS qubes [1]  tries to fix it, using domains and in each isolated domain, you have a dummy X. It supports clipboard.

Others solutions[2]  are being proposed to solve it.. however I don't know how it supports clipboard.

SELinux sandboxes[3] could be used as well. It very similar with OS qubes, but the main difference is that it uses the kernel to enforce isolation. Qubes uses XEN. First time that I tested, I wasn't able to copy and paste, but searching again, looks like it was fixed

References

[1] https://www.qubes-os.org/doc/copy-paste/

[2] https://wiki.gnome.org/Projects/SandboxedApps

[3] https://www.linux.com/learn/tutorials/382226-run-applications-in-secure-sandboxes-with-selinux


Field-level encryption vs disk encryption for PCI compliance We are in the process of setting up a PCI compliant server (with Firehost's help). We are using MongoDB as our primary database. I am having some concerns about the encryption, though. Are there any advantages of Field-level data encryption over Disk encryption (maybe with something like truecrypt)? Which would be the preferred choice for a PCI compliant MongoDB database server?

Field level encryption is important in case of SQL injections or your database server getting hacked. Assuming application and database are on different servers, the data will still be encrypted by application server.

Full-disk encryption would help in case of hardware theft as otherwise encrypted server will not be protected in case it is broken into as your encrypted partitions will be mounted so you database (MongoDB) can access it.

From this I would say that Field-level data encryption should be your focus.


Multiple users sharing the same IP I'm setting up a quite unusual proxy for a very specific niche case.

I'm allocating (ip,port) addresses to users, from which they can send and receive UDP and TCP packets.

e.g. say someone is allocated 1.2.3.4:50000, they can then send packets from that address and receive packets to that address.

Another person might be allocated 1.2.3.4:80, from which they can then send and receive packets.

Assuming our implementation is sound, and we allocate on IPs we control and ports > 0, are there any security liabilities here?

I know NAT is very similar indeed. I'm wondering as the user will be able to see and choose which of available IPs and port combinations to use, and thus there could be different potentially malicious users with access to port 25, 80, 443, etc, whether this breaks the assumptions of any important protocol.

I dont fully understand your question. Are you trying to limit users using particular IP and port?
In the real world we use random ports to connect to the target server port, i.e. you are using 65311 port to connect to google.com 80 port. So if you want to block the user's connection port from connecting to outside is quite usual. However you can still use NAT to limit what port can pass through the router from internal to external.

Moreover, you can assign MAC address to certain IP otherwise unauthorised or unset MAC address has no right to connect to outside.