What is more secure: ISDN, Cable Modem, DSL, T1, etc...?

On the physical medium part, eavesdropping on a phone landline where dialup modems are used is physically easier than spying on the more modern mediums, because the lower data rate more easily accommodates homemade electronics of questionable quality. Also, some of the protocols used over various mediums include encryption, which may hinder spying attempts on the physical line (at some point, I had an ADSL access with PPTP and some sort of encryption activated -- although I do not know how good it was !).

Although marauding in deserted courtyards during moonless nights, crouching under service boxes to add tapping wires, is a time-honoured spying tradition, I believe that most attacks nowadays will be on a logical layer -- the attacker will try to hack into the ISP systems, or the machines on the customer side, be it a cable/DSL-modem or a not-totally-updated desktop systems, and he will do so by sending IP packets from far away. These are mostly orthogonal to the question of what medium is used. Logical attacks allow the attacker to try his luck on millions of targets from the comfort of his own basement, instead of confronting rainy gloom and ill-tempered cats on the random chance that the dozen or so homes that he will approach that night may contain something valuable, electronically speaking, and that no bored insomniac will spot him and call the police.

Physical spying still exists, but is mostly employed on specific targets: the attacker does not want to spy on anybody, he is after you, personally. At which point you should have more pressing needs. Proofing a home network against a dedicated attacker is hard; think about TEMPEST or even about looking at your display and/or keyboard, over your shoulder, from the outside, through a window. A good telescope, a video camera with high fps (nominally for slow-motion), and you can record a typed password from 200m away.

So for the specifics of DSL/T1/Cable/ISDN, I would advise selecting the provider: choose an ISP with a good repute about security issues, in particular with regards to whatever modem he provides. That's more important, security-wise, than the physical medium. And, to abstract the whole question away, never do sensitive stuff over the Internet unless you employ appropriate logical protection, such as HTTPS.


what attacks are possible on outdated versions of TAILS?

Every new release of Tails lists the vulnerabilities fixed in this version. For example if you go to https://tails.boum.org/ and look down at "Security" heading, you will see "numerous security holes in ".

So indeed, there are vulnerabilities in the older versions of Tails. However for the sole purpose of downloading a new version of Tails those are less relevant, and many of those won't even apply. While it is still possible to attack you using those exploits (for example, by patching the downloaded image as you're writing it to USB), the effort required to implement and execute such attack is enormous. So unless you consider yourself a desirable target of a three-letter agency, you likely are ok.

Please keep in mind that most people download the new version of Tails on their regular operating systems, so security-wise they might be even worse than old Tails.


Is there any risk from attempting ssh authentication to a rogue server?

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments.

Question 1:

  can client public key be used to authenticate server

The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?).

Question 2:

  is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh keys to a rogue server will somehow leak information about his private key (stored only on his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in its certificate). This will allow you to authenticate the server and you will see that it is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case you still don't leak your private key by attempting to connect, since it is your (ssh) public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA and/or ssh is/are not broken).

I would also like to reemphasize that fact that I'm assuming the question is only directed at connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.


What is "-srvcert" in OpenSSL cmp command line?

I am citing from man openssl-cmp

  Server authentication options

  ...
  -srvcert filename
      The specific CMP server certificate to use and directly trust (even if it is expired) when verifying signature-based protection of CMP response messages. May be set alternatively to the -trusted option if the certificate is available and only this one shall be accepted.

So this option is used to authenticate the server but is not required.

The  example for enrollment in this man page does have a shared secret between server and client but does not use -srvcert at all.

openssl cmp -cmd ir -server 127.0.0.1:8080 -path pkix/ \
   -ref 1234 -secret pass:1234-5678-1234-5678 \
   -recipient "/CN=CMPserver" \
   -newkey cl_key.pem -subject "/CN=MyName" \
   -cacertsout capubs.pem -certout cl_cert.pem

My suggestion for now would be to omit server authentication and test if everything else works.


Do certificates contain private keys or other sensitive data?

This depends on what is considered sensitive. And this depends on the context.  For example it might already be considered sensitive information which domains are listed as subject alternative names in the certificate. Some of these domains might be already known by whoever views the certificate while others might be interesting new information, like maybe internal names.


Identify Encoding type - decoding base 32/64

The top part is clearly base64, (usually you can tell by the == at the end).

After decoding it, the result is 32 -  |3 Times A Charm| - 32.

CTF games and events (like hackthebox.eu, my favorite) usually are multi-step. Meaning this is likely a hint to the next step, not the answer itself.

The extra characters in an rtf are for formatting and are not meant to be included. They are just mostly carriage returns on my notepad.

Finally, you'd have better luck in the CTF forum.

Happy hacking.


How to find who granted local admin privileges to a user?

You can use Powershell to filter the right events:

Get-EventLog Security -InstanceId 4732

Heres a powershell command to get all the eventlog entries for which an user was added to local administrators:

Get-EventLog Security -InstanceId 4732 | `
Where-Object {$_.Message -like "*Administrators*"}`
| Select-Object *

Sadly I couldn't test the command because I'm at home and don't have access to AD. But you should get an Output like that:

EventID            : 4732
MachineName        : localhost
Data               : {}
Index              : 165325
Category           : (13826)
CategoryNumber     : 13826
EntryType          : SuccessAudit
Message            : A member was added to a security-enabled local group.

                     Subject:
                        Security ID:            SID of the user that added the user to the group.
                        Account Name:           bob
                        Account Domain:         contoso.com
                        Logon ID:               0x59461

                     Member:
                        Security ID:            SID of your friends user account
                        Account Name:           -

                     Group:
                        Security ID:            S-1-5-32-544
                        Group Name:             Administrators
                        Group Domain:           Builtin

                     Additional Information:
                        Privileges:             -
                        Expiration time:                %11
Source             : Microsoft-Windows-Security-Auditing
ReplacementStrings : {-, some sid, Users, Builtin...}
InstanceId         : 4732
TimeGenerated      : 26.01.2017 21:08:49
TimeWritten        : 26.01.2017 21:08:49
UserName           :
Site               :
Container          :

Maybe you need to change some stuff in my script, but you should have all the information, to find the admin.

Edit: Changed my powershell command. It still needs a filter to search for the individual user.


How can I snoop on a mutually authenticated SSL connection?

You may want to take a look to ReverseEngineering.SE as there may be some more practical information there. I also recommend you to check your product license and get some legal advise: while reverse engineering is usually considered a fair practice (from a legal perspective) when it comes to ensuring software compatibility, it is often a grey area and you may not want to put yourself or your company into trouble.

Your application is using SSL mutual authentication, which means that the server authenticate itself to the client, the client authenticate itself to the server, and the communication between both is ciphered.

What you need is called SSL interception.

This is basically done using some form of proxy which will fake server's identity to the client, fake client's identity to the server, and have access to the communication in clear form in between.

Normal communication:

CLIENT >client_cert>---------------------------------<server_cert< SERVER

Communication intercepted by a proxy:

CLIENT >client_cert>------<fake_server_cert< PROXY >client_cert>------<server_cert< SERVER

Fake server's identity to the client

This is usually done by installing a CA certificate you control (ie. one you created yourself and for which you have the associated private key) on the client.

Then install this CA certificate on the proxy with the associated private key. Now any certificate that the proxy will generate and sign using this CA will be trusted by the client. In particular, the proxy will be able to generate new certificates bearing the genuine server name, effectively spoofing its identity.

Note that there are measures that the client can take to detect that the certificate sent by the proxy is not the actual server's certificate, but if you are lucky (ie. if the developers did not take any specific step to harden their application) such measure will not be implemented.

Fake client identity to the server

As you have no control over the server, you therefore need a genuine client certificate with its associated private key. Fortunately, according to your post it seems that you have them, so it should be possible to install one of these client certificates on the proxy to make it able to identify itself as a genuine client against the remote server.


Are wireless card skimmers just fearmongering?

ScanBlocker seems like overkill, and depending on how the transmitter works it may even be illegal in some places.  RF blocking wallets are much cheaper, much smaller, and have fewer parts to go wrong.  My paper passport has an RF blocking cover; it needs to be opened a bit in order to be read.  My plastic passport card came in an RF-blocking Tyvek sleeve.  I've tested both and they have proven highly effective at preventing NFC reads.

The ads are correct in that NFC skimmers do exist.  Whether or not the card data that is visible to a skimmer is useful depends on the thief and the card.  The cards transmit the account number in the clear, but a successful authentication also needs another value, called the CVV, CVV2, CVC, or others.  If the card issuing bank used Static Data Authentication (SDA) to generate the CVV, the thief has everything he needs to create a working clone (most banks are smarter than that, however.)  If the card uses Dynamic Data Authentication (DDA), the thief will get a cryptographically generated one-time-use CVV number, and even that won't work after your card generates another number.  (The CVV2 is the short code printed on the face or back of the card, and the thief cannot read that electronically.)

Note that he still has the account number, but without a valid CVV it will severely limit the transactions where he can use the stolen number to primarily offline situations.

The larger question is if any of these measures are necessary.  Yes, there are NFC skimming thieves on the planet, but not as many as a scary advertisement would have you believe.  So the answer is "it depends."  Do you live in a populous area?  Do you frequently take mass transit, or sit in crowded public spaces?  Do you spend a lot of time in shopping malls, or busy airports?  The more people you expose yourself to, the higher the chances are that you could get skimmed. If you believe you are at risk, use an RF blocking wallet.


Is there a term for the combination of principal and credential?

One common term for this is "Credential Pair", which references the combination of identification token and authentication token, while recognizing that the bare word "credential" is often used to reference the authentication token.

Another term, used less commonly and with less precision, is the plural "Credentials", again referencing the combination of multiple elements.


How to mitigate risk of X11 buffer ghosting (palinopsia bug)

A partial answer:

What you call "buffer ghosting", is also known as palinopsia bug. The link provides a proof of concept, a short script to show your video RAM with content of already closed applications.
Other than regular RAM, GPU video RAM is not zeroed by default when it is allocated. Some drivers do it, some don't; zeroing the RAM slightly costs performance.

You can forbid an application to have access to GPU with untrusted cookies. Example:

xauth -f $HOME/mycookie generate . untrusted
XAUTHORITY=$HOME/mycookie glxgears

glxgears will fail to start because it has no GPU access. Using trusted instead of untrusted allows GPU access, and glxgears works.

Using untrusted cookies on a non-compositing window manager like i3 or openbox may be save. Compositing window managers respective desktops with 3D effects like Gnome or KDE may store window content in video memory even if the application itself does not.
I'm not sure if X itself may use video RAM in cases not preconceived here.

  This only happens on local X servers, not over ssh

Afaik, ssh always uses untrusted cookies.

  How do I feasibly mitigate or eliminate the risk of disclosing the information contained in these remnant buffers?

Never use your GPU (sigh). Yell at the developers Write a bug report. Don't view pron in chrome incognito mode.

The video RAM even survives a reboot from one system to another.

The only real secure way may be to disable GPU on kernel level.

From a security point of view, the driver should zero the video memory immediatly after deallocating, because the video memory can be accessed without using the driver and also persists after reboot. At least it should zero the video memory when allocated. Neither nore is done.

Some applications can have trouble with untrusted cookies. There is also the possibility to disable the OpenGL / GLX extension in the X server.
(Please regard that this has no effect for Wayland compositors like Gnome 3 Wayland session).

Create a file:

/etc/X11/xorg.conf.d/disable-gpu.conf

with the the content:

Section "Extensions"
    Option "GLX" "Disable"
EndSection

Instead of this permanent xorg.conf configuration you can run X a single time with GLX disabled. Start X from tty2 with startx -- -extension GLX vt2. (Set N in vtN to the number of the tty).


Why can't I send raw HTTP requests with arbitrary headers from a web application?

But I got the error Refused to set unsafe header "User-Agent"

Browser behavior varies here. Firefox allows unprivileged web applications to issue a custom User-Agent header to the same domain (or to other origins via CORS), but Google Chrome doesn't.

User-Agent is not in Mozilla's list of forbidden headers:

  Note: The User-Agent header is no longer forbidden, as per spec — see forbidden header name list (this was implemented in Firefox 43,) so can now be set in a Fetch Headers object, via XHR setRequestHeader(), etc.

But you will never be able to send the header cross-domain without permission. That's also why XSS flaws based on altered user-agent strings are usually not exploitable.

Beyond that, an unprivileged web application can't issue actual "raw HTTP requests" for obvious security reasons. Even if you write a browser plugin, chances are that you have to go through the respective higher-level APIs and can't entirely control HTTP requests on a byte level, as you could using netcat.


Does a VPN Router also encrypts the data being sent from a mobile device

what I can't seem to understand is if a VPN Router will add more encryption on the wifi via a secured & encrypted private tunnel etc. If indeed that's the case so how does the mobile device "knows" to "talk VPN and AES-256 encryption"? It would have to have a VPN also installed on itself, right? From the router to the outside world it's obvious - it gets encrypted and sent through a secured tunnel to the VPN server(s).

In order to use an end-to-end VPN (TLS VPN) you need a VPN client on your device and the encrypted tunnel goes from your device to the VPN provider. IPSec VPNs are different, because they are gateway-to-gateway, so it's actually the router which does the encryption, but IPSec VPNs are used for different applications than yours. In SSL/TLS VPNs the router doesn't do any encryption.

So yes, the mobile device must know to "talk VPN and AES-256 encryption". It does so by using some kind of client, which can be built-in in your OS or not.

  what happens on the way back? According to my knowledge as an App Developer, WhatsApp servers will send the response through GCM/Push message or even their own Push-Messaging service but they will send it to my actual mobile device IP. Both Android & iPhone keep an open channel with Google/Apple and tell them the location and your IP for fast & power efficient push messaging

To be honest, I've never tried using Whatsapp over VPN. However, any message arriving to a server through a VPN provider contains as source address that of the VPN provider server (this is why when you go on any "what is my ip" website while on a VPN, you get the IP address of the VPN provider). The server (in this case, WhatsApp server) reads that address and replies back to that. VPN tunnels are not negotiated by anybody except by VPN endpoints.

Yes, some applications may not accept VPNs for whatever reason - they can do so because they recognize that an incoming packet has a source address belonging to a known VPN provider - but  no application that I know of uses another IP address than the one contained in the "source address" field of the received packet.

While theoretically possible, it would break several fundamental principles of the Internet, besides being nasty by itself. Google can be nasty in some ways, but doing the equivalent of

  You're telling me to send you stuff at this address.... but I know where you really are, so I'm going to send everything there! You can't hide from me MUAHAHA

is probably way beyond Google/Apple/... levels.


DirtyCow is a linux kernel vulnerability - an error in implementation. MacOS X is BSD based - completely different code base. While in principle there could be a similar vulnerability, it is very unlikely that a Linux based exploit for a Linux based vulnerability would operate on MacOS.


External IP same as Internal IP security

If your pc has a firewall which blocks all incoming packets, and is patched up to date then you can be relatively safe. I wouldn't recommend it though, add you are missing layers of protection which a router can give you.


Preventing printed data interception using origami or other technique?

I've never heard of a cryptographic operator that works like this—you could certainly design a page that looks a certain way (e.g. has certain numbers on it) when folded up, but I've never heard of an automated way to do that.
In part, this is because you have one whopper of an XY problem here. First of all, I sincerely doubt your threat model is accurate—everyone and their aunt has a smartphone nowadays. Second of all, there are much more effective and less finicky ways to do what you'd like—for example:

Print thousands of codes on one page. Remember that the (n)th (9th, 73rd, 50th, whichever you choose at the time) one from the bottom is the real code. You need to use a different (n) each time, or you become vulnerable to known-plaintext, whenever someone figures out one of the real codes, notes where it is, and can steal the real codes from all the other pages.
Print thousands of codes on one page, prefixed by various letter combinations. Remember which letter combination you put before the real one. You need to use a different letter sequence each time, or you become vulnerable to known-plaintext, whenever someone figures out one of the real codes, notes what letter sequence it started with, and can steal the real codes from all the other pages.
Bypass the printer and write it down on a piece of paper with your own hand, it's just a 10-digit code...


Is it possible that to sign a message with a PGP key in a way that leakes the key

PGP signatures, like most modern signature schemes, are not deterministic: that is, signing the same message twice will not result in the same signature. To do this, a random nonce (number used once) is used. The nonce needs to LOOK random, but there is no way of guaranteeing that it is: you could encrypt some data you want to exfiltrate with a fixed key, and it would be indistinguishable from a proper nonce. The signature would still verify, but someone "in the know" could decrypt the nonce to recover the exfiltrated data.

That being said, nonces aren't usually big enough to hold a full private key. You could easily mitigate this by exfiltrating a random segment of the private key with each message; the recipient could then piece back together the key after seeing enough messages.

Edit to follow up: the naive method described above produces the same signature each time, a dead giveaway. It's pretty easy to fix though. The nonce in a protocol is usually long enough to provide cryptographic strength, which is more than enough to include a few random bits to ensure the malicious signature can't be detected. For example, you could split the nonce in half; the first half could be truly random, and the last half could be a portion of the private key encrypted with using the first half as an IV. As a further improvement, the first byte or so of the exfiltrated data could be used as an offset, showing which piece of the key is being leaked in that message.


How to view all SSH authorized_keys for a unix server

To answer your questions in order:

You can see all authorized keys by running the following script with root privileges.

#!/bin/bash
for X in $(cut -f6 -d ':' /etc/passwd |sort |uniq); do
    if [ -s "${X}/.ssh/authorized_keys" ]; then
        echo "### ${X}: "
        cat "${X}/.ssh/authorized_keys"
        echo ""
    fi
done

Any valid user may create a $HOME/.ssh/authorized_keys file and add any number of public keys to it.  Someone with the corresponding private key will then be able to log in as that particular user.  The process sshd follows is like the following.  When a new connection comes in sshd asks the client for the username.  If the username exists in /etc/passwd, sshd then reads the name of the user's home directory from the sixth field in /etc/passwd.  It then checks if .ssh/authorized_keys exists in that user's home directory and if permissions are correctly set on both the .ssh directory and authorized_keys file.  If those conditions are met, sshd will then attempt to authenticate the client's private key against the public key stored in $HOME/.ssh/authorized_keys.  If the client possesses the matching private key, sshd will allow it access.
You may use the script above.

S.L. Barth makes an excellent point about root access.  It is considered a risk to allow root access through ssh.  The generally accepted practice is create a user account, grant it root access with sudo or a similar tool, and disable root logins through ssh by adding the following line to /etc/ssh/sshd_config and restarting sshd.

PermitRootLogin no

Chances are almost 100% that if your machine is on the Internet that the "Hail Mary Cloud" will be knocking at your door.  For Linux, iptables, and sshd where you allow password based logins, you will probably want to install and configure something like fail2ban so it's harder for attackers to brute force your machine.

And, since we're already talking about ssh keys, and because this was posted today, you probably want to add UseRoaming no to the Host * section in your /etc/ssh/ssh_config


Safe usage of Runtime.getRuntime.exec(String[])

I ran your program, linked to a checkfileindirectory.sh that looks like this:

#!/bin/bash

echo $1 > param1.txt
echo $2 > param2.txt

As a test, I changed "<file_to_find>" to "<file_to_find>;touch MikeWasHere.txt"

String[] cmdArr = { "bash", "checkfileindirectory.sh", "<directory_to_search>", "<file_to_find>;touch MikeWasHere.txt" };

And I get this output:

➜  /tmp javac FindFileInDir.java
➜  /tmp java FindFileInDir
➜  /tmp cat param1.txt
<directory_to_search>
➜  /tmp cat param2.txt
<file_to_find>;touch MikeWasHere.txt
➜  /tmp ls MikeWasHere.txt
ls: cannot access 'MikeWasHere.txt': No such file or directory

So it looks like java's rt.exec() is injection-safe.

OWASP's page on command injection has a paragraph about java's exec (emphasis mine):

  C’s system function passes its arguments to the shell (/bin/sh) to be parsed, whereas Runtime.exec tries to split the string into an array of words, then executes the first word in the array with the rest of the words as parameters. Runtime.exec does NOT try to invoke the shell at any point. The key difference is that much of the functionality provided by the shell that could be used for mischief (chaining commands using “&”, “&&”, “|”, “||”, etc, redirecting input and output) would simply end up as a parameter being passed to the first command

That seems consistent with our experiment that java's rt.exec() is injection-safe.


rsm's answer is pretty wrong - there are vulnerabilities for SIM cards. An attacker can install an applet on your card (it probably won't happen because it really difficult to find those vulnerabilities).

After the installation, the SIM card can transfer data to phone or make the phone open a url and download a file (proactive commands).

So yeah - it's possible to store a virus (more like a stager) and run from a SIM. In theory (I don't think it exists), it's possible to setup a botnet from SIM cards.


WebRTC shouldn't leak from a full, transport layer VPN ... right?

WebRTC leak and IP leak or DNS leak are two different terms and one shouldn't relate them with each other.

Why DNS leak happens?
When you use VPN and if you find that your IP is leaking it means your DNS request are also being forwarded to your ISP other than to your VPN provider. Your DHCP server chooses its own DNS server for fast response. This causes the DNS leak. You can test if your IP is leaking while using VPN dns leak

In WebRTC leak servers and browsers come to know about your internal IP Address if you are befind NAT but not all web-servers can do that.

How it works
Today your browsers are implemented with WebRTC. WebRTC accepts STUN request which is generated by STUN server. This request discovers behind which type of NAT you are sitting at and your public IP Address. WebRTC accepts this request and sends a response to STUN server that returns your NAT type and both public & private IP. STUN server uses 2 IP Addresses.

I wrote that not all web servers can discover your internal IP. The reason is not all web servers use STUN server because STUN server is designed for troubleshooting problems related with VoIP and NAT and how NAT creates problem in SIP&SDP.

While using VPN you might be able to prevent yourself from DNS leak but you can't prevent webRTC leak. To know your internal IP visit here. If you analyse the traffic of this site in wireshark you will see that it is generating STUN request.

How to prevent DNS leak
dnsleaktest.com serves a utility which blocks outside dns. I'm also using this tool. You can also flush dns cache using ipconfig /flushdns in command prompt or set static DNS address to Google or openDNS.

But remember preventing DNS leak doesn't mean you are preventing yourself from webRTC leak. VPNs doesn't block STUN request because it is just an internet traffic coming from STUN server.

STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery

How to prevent WebRTC leak
In google chrome there are 2 browser plugins WebRTC Leak Prevent and WebRTC Network Limiter. They successfully block STUN request and I'm using them both just in case if one fails to do that. It also means that by blocking STUN request my browser won't be able to make VoIP sessions when I'm sitting behind NAT.

Mozilla Firefox users can actually turn off the default WebRTC functionality directly in Firefox settings by typing ‘about:config’ into the search bar and browsing to the ‘media.peerconnection.enabled’ option and setting it to FALSE.

WebRTC leak has nothing to do with how secure your VPN is and how strong encryption your VPN uses. The vulnerability is in your browser which is WebRTC itself. Your VPN will simply accept any traffic you have requested.Strictly saying, VPN doesn't prevent webRTC leak
It all depends on your browser. If webRTC is enabled it'll simply accept STUN request and send a response to server.

You can learn more about webRTC leak here


Unauthorized API Access Without Key Header

There is not much known about your actual setup. But apart from trying to guess the key (i.e. brute forcing) the attacker might also

Try to sniff the key on the wire
Proper use of HTTPS will protect against this unless the attacker can make the client accept its own certificate and thus be a man in the middle.
Extract the key from the client side
Nothing is known about the client application. But a mobile application using the key might be reverse engineered, in a web application the attacker might use developer console to see the actual traffic in plain, XSS  issues in the client application might allow the attacker to extract the key from the client ...
Hack the server side and extract the key
For example using an SQL injection if the key is stored in a database etc
And maybe through other ways
For example because the developer inadvertently leaks the key when publishing the source code etc

  Is my API secure against a possible attack?

Your title asks about unauthorized access while this part asks about "secure against attacks" in general. Securing the key is not the only thing for securing an API. You should never assume that only a client fully controlled by you can use the API. This means you should also have proper input validation of what the client sends and not rely on the client to send only valid input. Additionally to this there are other attacks like DoS and maybe more. Again, too few is known about your actual setup in order to evaluate the security in more detail.

In summary: if you rely solely on the secrecy of the key your API is likely not secure against attacks.


That is very weird. The tools shouldn't lie. The networks are not changing its configuration by theirselves. Maybe the same network changed its config (done manually by network's owner). Anyway, If you want to compare results you can check with different tools. I can recommend to you some of them (scanner tools) for Linux and Windows:

airodump-ng <- is in aircrack suite
kismet
inssider <- is not free
netstumbler <- pretty old
acrylic <- free version is only scanner

Of course there are a lot of tools to audit wireless networks, not only for scanning. You can check some of my favourites:

airgeddon <- wpa/wpa2, wps, DoS, handshake capture, Evil Twin, etc...
linset <- Evil Twin
wifihacker <- wep, wpa/wpa2, wps


How do I run an unknown .exe file without being in risk

If you really want the closest thing to a 100% safe way of running malware:

Create an account with Amazon Web Services, fire up a server but don't connect it to anything (read: put it in its own VPC) and do your analysis there. Burn after analyzing.

Side note: there are some pre-created AMIs in the " Ec2 Market Place" that have malware analysis tools loaded on them already if you feel like getting frisky.


Check fingerprint for own self signed SSL certificate

Not sure if you mean manually or automatically.

Manually -- yes -- you can view the thumbprint of the certificate that reaches your browser, e.g. in Chrome you would right-click the part of the address bar to the left of the address, choose Details, View Certificate, and click on the details tab.  The thumbprint is at or near the bottom.

Automatically -- yes -- just install the certificate on your desktop computer (double click the cert and follow the instructions) and the browser will trust it from that point forward.  If one day you browse to your web site and you get an SSL warning, there was a cert mismatch, and someone is hacking you.


Can an attacker "simulate" a private IP address?

Before the attacker can send any data to the SSH server, he has to complete a TCP handshake. This means the attacker has to guess a 32 bit sequence number. (If SYN cookies are used, the attacker's chances may improve.)

Assuming your server is generating good sequence numbers, this will significantly reduce an attackers ability to attack your SSH server using a spoofed client IP address.

But maybe you don't trust your server to generate good sequence numbers, or maybe you think 32 bit of security isn't good enough. So you might still want to know, what would happen once the attacker guessed a correct sequence number.

First of all we notice that the attacker will be able to figure out whether a guessed sequence number was correct or not. A correct guess will cause a connection to be opened, so it will count towards the limit specified using MaxStartups. The attacker can attempt to open another connection using a non-spoofed address in order to find out if that limit has been reached. He can keep your server just below that limit at all times, such that a successful connection with a spoofed address would always take the last available connection.

Without the trick to notice a successfully guessed sequence number, the attacker would have had to send password guesses in the blind without knowing whether the connection they were send across even exists. That could potentially have slowed the attacker down by a factor of 2³².

But even though an attacker can get feedback to indicate whether a sequence number was guessed correctly, there are other roadblocks preventing password guessing on a spoofed TCP connection.

During key exchange both client and server will choose a random value to be send over the connection. These random values influence the session key. This means an attacker working in the blind (because he doesn't see replies send from the server to the spoofed IP) will not know the session key.

The lack of knowledge about the session key means the attacker will have to guess a message authentication code. This is essentially equivalent to performing a MITM-attack on a legitimate connection. Additionally, the attacker has to send the password encrypted to be decrypted by the server. Since the attacker don't know the encryption key in use, he will not know which passwords he has tried.

The time window for the attacker to complete the attack only lasts until the spoofed IP address has replied with a TCP RST packet. Since the roundtrip time between attacker and server is likely going to be larger than the roundtrip time between server and local addresses, this could prevent the attacker from using any sort of feedback including the verification of correctly guessed sequence number.

You can give the attacker a longer window to complete the attack by installing a firewall that prevent the SYN ACK from reaching the spoofed IP address or by preventing the RST from reaching the server. This does however not make the attack much more feasible.


When using multiple operating systems, can they affect each other?

Windows will have full hardware device access while it is running.

If the Linux partitions are encrypted the data within them is safe from exposure that way.

However malware infections obtained while running Windows could manipulate the bootloader to produce a fake disk encryption prompt that steals your master encryption key.  This is fairly elaborate, but not inconceivable if the motivation is sufficient.

It's a trade-off.  If you dual boot, be sure to use full disk encryption on both OSes to prevent them from seeing each other's files.

If you want full separation you are better with separate hardware for each OS.

A great option proposed bt @R.. and @NathanOsman in the comments is the use of a hypervisor to run the more at-risk OS.  In practice I run Windows inside VirtualBox, but there's an even deeper solution to this called QubesOS which runs Xen on the hardware and runs apps in AppVMs using windows seamlessly integrated into a shared secure window manager.

A third option (with bare-metal perfomance for Linux, Illumos, and Solaris 10 or under native apps) is OmniOS or SmartOS with lx-branded zones and KVM.  There's no QubesOS-equivalent window manager for that approach yet so you'd have to use VNC or Spice to access the screens of the VMs.


How to find default S2K parameters in GPG

According to the Tails source, no custom S2K counts are specified for GnuPG. This means you will be using the default for the current version. The changelog for Tails shows that 3.7.1 is using both 2.1 and 1.4. For 2.1, the count seems to be variable and depends on your hardware's performance, with a minimum of 65536. Version 1.4 on the other hand hardcodes the default at 65536.

The S2K version will always be 3 as is the case for all modern GnuPG setups. As for the default digest algorithm, for both 2.1 and 1.4, SHA-1 is the default. Note that there is an open bug that may make it such that the various S2K options in 2.x do not do what you think they will do.


What is the exact difference between SAMLp and WS-Trust?

WSTrust is a standard which is specifies how to encrypt/decrypt/sign SOAP messages and how to bind security tokens to a SOAP message.

SAML tokens are an example of a security token that could be bound to a SOAP message.

The SAML protocol provides a standard way to acquire, release and renew SAML tokens using SSL to protect communications and the XmlDsig standard to protect the token.


Want to build a password manager using OpenPGP.js

[Disclosure: I, too, work for a password manager company]

Long ago, I tried to develop my own password management solution using PGP/GnuPG. As I thought more about it, I found it unsatisfactory and eventually switched to the one that I have now come to work for.

Here are some things you should consider before trying to roll your own password management system:

What is your source of randomness for key and password generation?

Do
you know how to use a cryptographically secure random number
generator and why it works the way it does
What is your key derivation function?

Does it use something like
PBKDF2 to resist password cracking attempts against your master password?

Do you know how all of the choices in your KDF interact and stand up against
current and foreseeable attacks?
How much sensitive data remains decrypted at any one time?

If you
decrypt an entire file, then all of that decrypted data will need to
reside in memory or virtual memory on your computer, leaving it
potentially exposed after a crash, in memory, in automatic backup
files, or in system swap files
What measures does the system have to prevent data loss?

Does the
(automatic) back up system perform any integrity checks on the data
prior to making a backup?
How is memory of sensitive data cleared when it is no longer needed?

Are there obfuscation techniques for sensitive data (such as
decryption keys) that may need to reside in the app’s memory for a
while?
Will your system automatically lock or does it require you to take
action to lock/close your data?
Can you eliminate or minimize the use of Copy and Paste of sensitive
data?
If you build in web browser support are you aware of the kinds of threats against password management tools "in the browser"?
And most importantly, can you keep up with all of the research and
development on all of these (and other) issues that may require a
change in design or implementation?

You do not have to have a satisfactory answer to all of these to try to roll your own. But if you wish to "ignore" some of these questions you should do so deliberately.

I wish you the best with whatever you decide to do.


Does randomness prevent collision attacks?

Yes, randomness that is controlled by the signer and that (crucially) is unpredictable by the attacker eliminates the potential for a collision to be generated, including the chosen-prefix style of collision attacks that were used by researcher to create a fake CA in 2008, and the authors of the Flame malware to create a fake signing certificate a few years later.

The reason is this: To create a collision attack, the attacker must have control over both inputs.  That doesn't mean that both inputs are necessarily entirely arbitrary./ Indeed as you know, they certainly aren't, either for the forged certificates, or for the PDFs that Google created in their experiment.  There is quite a lot of structure in fact.   However, they attacker still needs to know exactly what the fixed components of the two inputs are, in order to be able to generate the components of both inputs that will ultimately allow the hashes of the full inputs to collide.

So, when the attacker does not control and cannot predict what the final form of one of the input is, he cannot create in advance the data that would need to be in the input he submits to the signer to sign.   He only discovers afterwards the full input data (including the nonce) and the resulting hash.  This fundamentally changes the problem from the need to create a collision, to the need to create a second pre-image, which as you've noted is a much, much harder problem, and something that is not even currently possible with MD5, if it ever will be.

So, I would say that yes, the introduction of unpredictable randomness does indeed eliminate the potential for collision attacks as a class.


You noticed the unfulfillable requirement: you are never told that you are ready to write crypto code.

I think the reason the "never roll your own" recommendation is always advised is because one is seeking recommendations.   As a lower bar, the point where you no longer rely on public opinion for advice is when you can start thinking about crypto.

And, at that point, you fully assume all responsibility for what you create.  The social group of developers never told you you could do it.  You just decided to do it.  And you live with the consequences.

Now, more specific than that, several experts recommend first trying to break other's crypto libraries before trying to write your own.  Once you can break what's out there, you are more likely to be aware of all of the nuanced pitfalls that come with writing your own library.

But myself, I think of it with a martial arts metaphor.  Think of an art where the black belt test is notorious.  It shreds egos like it was As Seen On TV.  You only get to take the test once.  So many ask "am I ready for the test?"  And the answer is invariably "You are never ready for the test."

So when  are you ready for the test?  When you realize you don't need a test to let people know you're good enough to be a black belt.  You know it.  So you just put on a black belt, stare down the experts who were supposed to give you the test, and they nod as if to say "yep, that was the trick the whole time."


OIDC: should the provider have the same address as the issuer?

Yes, the requirement is stated in the provider configuration section of the specs (emphasis mine):

  OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string /.well-known/openid-configuration to the Issuer. The syntax and semantics of .well-known are defined in RFC 5785 [RFC5785] and apply to the Issuer value when it contains no path component. openid-configuration MUST point to a JSON document compliant with this specification and MUST be returned using the application/json content type.

It also goes on to mentions that:

  The issuer value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information. This MUST also be identical to the iss Claim value in ID Tokens issued from this Issuer.

In practice I'm aware that a few of the mainstream providers such as Microsoft doesn't stictly follow this pattern but you'll have to take it up with them, or consider the workarounds given by the OIDC library.


As mentioned, there are no constraints on valid keys. This would limit the keyspace, making the algorithm less secure.  You say you don't have reverse engineering skills to throw at this problem, and you don't mention the app used. This leaves us at a dead end because we can't help as far as i can see. You could however try detecting the magic constants with an IDA plugin like FindCrypt (http://www.hexblog.com/?p=27), that would require only basic use of RE tools.


Is it possible to calculate an encryption key when both the plain text and ciphertext are known?

In answer to your main question, AES256 is secure as far as we know into the foreseeable future.  However your authentication scheme has several drawbacks.
First, if any request where the token is sent is compromised, or if a the user installs a malicious addon that can grab the encrypted user name from their browser, that account is forever unusable.  You are essentially creating a token to use for authentication that cannot ever be changed and that is a 1:1 relationship with the user name.  The only way to deny access if it is compromised is to shut down the account and force the user to create a new account with a different username.
A much better way would be to generate a random token when the user authenticates and store that in the database, or generate a random value and encrypt that as the token.  Then if the account is compromised or if the user wishes to 'log out', you can remove that token and generate a new one.
If your encryption key is ever compromised or if it is ever cracked somehow, the attacker can do anything as any user in your system.  With a random token based approach, they would have to know the random part used to generate the token for each user.  The attacker would have to have access to your database and your encryption key.


DOM-based XSS is something you want to look out for.

You might have code in your video player that reads out part of the URL - for example to get the id of the currently playing video or some video settings such as width - and inserts it into the DOM, leading to XSS.

Other than that, there isn't much that you can do wrong. Your Video player server only serves a static file, so if the server software itself is up-to-date, there shouldn't be any danger to it. Your script will also not be able to do any damage to Website, as that server should of course validate any user input it gets.


When applications process data, they need it unencrypted in RAM, and the data will be copied to many places, including the hard disk as temporary files, or as part of the virtual memory mechanism, or hibernation. If you need to ensure that, once the machine has been powered down, its contents cannot be retrieved by an attacker with full physical access to the machine (the "stolen laptop" scenario), then full-disk encryption is required, with the following caveats:

When we say "full", we mean "full". The disk containing the operating system core files should also be encrypted, and the areas for virtual memory as well. That's what TrueCrypt calls system encryption.
This is valid only for a powered-down machine, not a system in "suspended" or "hibernated state".
Even after power down, some data which was in RAM could still be readable for a few minutes; this is the cold boot attack. For most usage scenarios, this is not a hard problem, but it still pays to keep that point in mind.

File-based encryption tools (e.g. what 7-zip offers) are meant for protections of files in transit, e.g. when the file is to be sent as an attachment to an email, or stored on a USB key. This is not the same attack scenario.


Cross site scripting and the use of http-only cookies?

There are two major attack patterns that can be explored by an attacker armed with an XSS vulnerability that affects an application that uses HTTPOnly cookies.

First and foremost an attacker can use an exploitation method similar to the Sammy worm.  In this attack pattern the XSS payload uses an XMLHttpRequest to read a CSRF token and perform an action as if they where the victim.  Common actions would be, adding a new administrative user,  changing your password (or email address to perform a password reset)  or even transfer funds.  Any action that the authenticated session can perform,  you should be able to perform with JavaScript by reading CSRF tokens.

The second attack is leveraging a trusted domain.  Lets say the target is  https://sometrustedbank.com.  That HTTPS looks pretty shinny to informed users,  but an attacker can modify any content on this page by assigning document.body.innerHTML to any value.   An attacker could conduct a very convincing phishing attack where by a helpless victims are directed to https://sometrustedbank.com and asked to divulge personal information (and deep dark secrets).  In this case the content is king,  and a user is unaware that this content originates from an attacker.

In short; enable HTTPOnly Cookies, but know that this security feature was never indented to stop XSS.


As of late, there has been a best practice in the DevOps Community:

If it's not automated, it's not secure.

Automation provides benefits for security (e.g. limited, audited access via configuration management, e.g. Puppet, Chef, SaltStack), but also for availability and ease of support.  As far as availability goes, it should be fast to roll back changes as well as QA them to detect issues.  For ease of support, it no longer relies on one-off ssh commands etc run by system administrators, instead a fix is automated and can be easily reproduced.

In these environments, remote access via SSH etc to individual servers is generally disabled.  Instead, one must use the configuration management system to push any changes -- or simply deploy a new server, depending how the DevOps stack is designed.

SELinux can also be leveraged to make it so that system administrators do not have access to actual data, only sysadmin functions.  However, this is very cumbersome to maintain and is not commonly practiced, to the best of my knowledge, outside NSA and other high-security state-backed entities.

To detect and potentially prevent data loss/leaks, a DLP solution can be invoked.  This can be installed on servers (via configuration management) and will be triggered if a sysadmin attempts to download data, etc.  These solutions are often expensive, but offer a last-line of defense against rogue staff.

Corporate policy can also address remediation efforts -- if it is made clear to the sysadmins what activities might violate corporate policy, and sanctions are made clear in the policy; this may have a strong deterrent effect against potential leakers.

In the end however, a sufficiently clever sysadmin can likely circumvent most of these protections eventually.  To cite the old aphorism, "Locks keep out honest people."  You can add as many locks as you like, if you have staff dedicated to nefarious activities it will be difficult to stop them.


How to distribute software with one time installation key in complete offline

Here is an approach that partially solves the problem: Probabilistic encryption to generate installation keys.

When a user wants to install the software, they call you and give you their MAC address. You append the MAC address with the current UTC timestamp and encrypt it with a probabilistic encryption(PCBC or something similar) scheme and send the installation key using SMS.

The computer decrypts the installation keys and verifies the MAC and timestamp. IF the timestamp is of upto a tolerable time before current time (you neeed to factor in slow typing), then the software installs otherwise not.

Please keep in mind that this is not a completely foolproof mechanism. There can be multiple machines installing the software together and doing a MAC spoof. Also, you will have a challenge in keeping the generated installation key to human readable characters.


How to "get in sync" with what is happening in the security scene right now?

From looking in the right hand column for "Related" posts for this question, I have the following:

Resources to learn about security
What resources should a white hat follow
List of good security blogs
Best security conferences
List of security podcasts

These have some good value links.

I tend to add the best ones to my RSS feed and read them in Google Reader while on the train commute.


The presented mitigation is absolutely insufficient. It’s not just possible to include any file from the current directory but also from any directory depending on the file system  (i. e., \.. still works on Windows) or by using an absolute path (e. g., /… on Unix-like systems, or \… on Windows) as well via different protocols/wrappers (e. g., http://…, file://…, ftp://…, etc.), allowing the execution of arbitrary PHP code.

If you don’t want this, you should validate the parameter value. For example, if you only want to allow certain values, use an array and check whether the given value is in it:

$validValues = array();
if (!in_array($page, $validValues, true)) {
    die("invalid 'page' value");
}

If you want to allow any file within a certain directory, you could check whether the resulting absolute path is still pointing to a file within that directory using the technique described in Preventing Directory Traversal in PHP but allowing paths.


Why would TLSv1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA still be used?

The used protocol and ciphers depend on the capabilities of both client and server. You don't say what kind of server is involved but usually today's TLS stacks on the client side offer a variety of ciphers and also still support TLS 1.0. If the server cannot do better than TLS 1.0 then this is what is used as the minimal protocol version. The for the cipher: the server picks the one which is both offered by the client and supported on the server. And, while TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA might not be the most modern cipher it is perfectly safe to use today.

Thus, in order to find out who is to blame for TLS 1.0 and for the cipher look closer at the handshake, i.e. look at the ClientHello on what the client offers (as  dave_thompson_085 correctly pointed out: look into the "inner" version and not the record layer version). If the client offers TLS 1.2 and the resulting protocol is only TLS 1.0 then the server is to blame for this and not the client. The same is true for the choice of ciphers, i.e. at the end the server decides what to use.

As to why a server still might support only TLS 1.0: it is probably some older system which does not support newer versions yet. And, since the cost of upgrade is not zero (not only the cost of software but also the cost of testing everything which depends on it and maybe more) the owner decided to not upgrade to a more modern system.


What's a good tool or website to help learning about security?

Sorry, i don't know the game you are actually looking for, but i recommend you OWASP Webgoat or OWASP Webgoat .Net if you like to train your programmers secure web-development.

If you like to earn points or kudos: security.se or search the net for "hackits"


Does CVSS v3 evaluate the impact of vulnerability on the host?

Yes it does.  A CVSS 3 base score is calculated using eight factors:

Impact is determined by: scope, confidentiality, integrity and availability.
Likelihood is determined by: attack vector, attack complexity, privileges required and user interaction.

A good place to learn about these is the online calculator.

The problem with CVSS and Heartbleed is that it doesn't account for chained vulnerabilities. The real concern is that an attacker uses Heartbleed against your VPN server, steals credentials, uses the credentials to connect, then wreaks havoc on your network. Using CVSS you only consider the first bit, so there is no impact for confidentiality and integrity. And with CVSS 2 the confidentiality impact is "partial" not "complete".

CVSS 3 works a bit better; I score Heartbleed as 8.6. Impact ratings are now low/high instead of partial/complete. Heartbleed is certainly high confidentiality impact, even if it's not complete. They also introduce the somewhat obscure "scope" factor. Heartbleed has changed scope, as you're accessing memory outside the intended scope of an SSL connection. However, CVSS 3 still doesn't account for chained vulnerabilities.

There are also CVSS temporal and environmental scores which add additional factors. The idea is they help you measure things like "this particular box is great risk right now". However, I've found temporal and environment scores to be rarely used and not particularly helpful.


authorization vs federation vs entitlement

Authorization is the access policy stating to which protected objects or services a client has access.

Authentication is the proof of identity that the client provides to validate his authorization.

Federation (usually identity federation) is to make one central online identity valid over several different services. Google Accounts and Facebook Connect are identity federation systems.

Entitlement could be anything IMO. The closest I get is that when you are authorized access to a service or object, you are entitled as authorized to that service or object.

This way, to get access to your Security.StackExchange account, you may authenticate with your Google Accounts ID and find that you've (earlier) authorized StackExchange to use your Google ID credentials at that service. Also, when authenticated, you find that your Google Accounts user is authorized to access StackExchange, and you are approved access.

A classic misconception is that authorization is the same as access approval, although authorization is established in the registration phase (happens only one time), but access approval is done each time, based on the authenticated user's authorization, looked up in the access policy.


Is there webapp login, password creation and maintenance, and user verification code in php?

I do not know that PHP answer, but strongly suggest you don't use Basic Authentication. This is a very poor form of username/password security and is extremely easy to decipher for a website pentester...and an attacker. Please see owasp.org for secure website information. I would think your PHP question would be better answered here: https://stackoverflow.com/questions.


What is the purpose of the CA-BUNDLE on a webserver?

All browsers inherently trust DigiCert

True enough.

  (and I assume it's intermediate CA?)

Clients may include trusted intermediate certs, but cannot be expected to.  It is your job, the server, to provide any intermediate certificates necessary to validate your certificate chain up to the root (RFC 5246 7.4.2):

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

  The only thing I can see is if the client doesn't have one of the intermediate certificates installed it can ask my web server for it (and verify it against the in-browser DigiCert root)?

Correct.  That's exactly the reason.


Found a backdoor and multiple trojans in a computer. Is the hacker doing everything manually?

You can do this operation from all over the world.
And also control the computer remotely every time you turn the computer on. The hacker is notified about this and can do operations like listening to audio/video from pc and also each key the user types.
The hacker can also infect other devices on the network.
You must isolate this PC ASAP and change the passwords for each user account immediately from another device.


Prevent Cross-site WebSocket hijacking with a custom header and no CORS

RFC 6455 says:

  Servers that are not intended to process input from any web page but
  only for certain sites SHOULD verify the |Origin| field is an origin
  they expect. If the origin indicated is unacceptable to the server,
  then it SHOULD respond to the WebSocket handshake with a reply
  containing HTTP 403 Forbidden status code.

and

  The |Origin| header field [RFC6454] is used to protect against
  unauthorized cross-origin use of a WebSocket server by scripts using
  the WebSocket API in a web browser.  The server is informed of the
  script origin generating the WebSocket connection request.  If the
  server does not wish to accept connections from this origin, it can
  choose to reject the connection by sending an appropriate HTTP error
  code.  This header field is sent by browser clients; for non-browser
  clients, this header field may be sent if it makes sense in the
  context of those clients.

The simplest fix is to check the HTTP origin header on the server side against a whitelist. Your library/framework may already provide secure defaults (no CORS) or have a way to configure this without requiring you to reinvent the wheel.

Since you do not expect any CORS requests, then you should verify that the HTTP origin header matches the URI of your website. According to the RFC, websocket upgrade requests should include this origin header. I confirmed on my own webapp that the header is sent even for the same origin.


Why does Tor browser use POST method for DuckDuckGo?

With POST the actual search is not part of the URL. It will thus not be visible in the Referer header to a potential remote side and it will also not be part of the local history. See also this comment in the Tor issuer tracker about the setup of DuckDuckGo in the Tor browser:

You should probably do a POST request here as the value of the searchTerms parameter will be leaked as part of the Referer header.


How do AVs scan the file in websites that claim they don't send the files to AVs like Nodistribute.com?

I believe that they send the files, the reason I think they do is because in the past there was a site that was well known for not sending the files.

It was most known by malware builders, their owners end up with problems with justice accused of helping malicious actors and allowing them to tune their malware, basically partners in crime.

You can search for reFUD-dot-me

If they are really doing it, there is a good chance they will end up as the  reFUD...

https://www.theregister.co.uk/2018/02/15/refud_cryptex_kingpin_goncalo_esteves_jailed/

Or

https://www.zdnet.com/article/hacker-gets-a-whopping-14-years-in-prison-for-running-scan4you-service/


Is it possible to execute Server Side Scripts despite Content-Type header?

In a perfect (and bugless!) world, it would not be possible. An image file should always be recognized as an image file by the web server and handled as such, this means:

Setting the mime-type accordingly for a proper display on user's browser,
Raw file data sent to the user's browser: no script executed.

However, things turn wrong when there are possibilities to trick the web server into thinking that this .jpg file is actually an ASP (or whatever) script to be executed. The web server will then open this file as a script, execute its content, a be screwed...


Can a website determine what OS or webbrowser a visitor is using if the useragent is blanked/changed?

If you allow the website to run Javascript which can send code back to the server there are probably multiple ways to detect the browser as different browsers handle things slightly different.

Apart from that there are also user variables besides the user agent with identify the browser. See http://www.quirksmode.org/js/detect.html and http://www.quirksmode.org/js/support.html


Is this VPN customer service info correct?

Your DNS queries will not be visible to your ISP or anyone watching your ISP connection (assuming you are routing all your traffic through your VPN), but will be visible (but not traceable to you, unless you are the only user of that VPN) from the VPN exit point to the OpenDNS provider.

Note that if the VPN provider logs traffic, those logs would be visible to anyone who can compel the VPN provider to turn them over and the DNS requests would be visible then.

And, of course, everything you do will be visible to your VPN, unless you use further encryption. For example, even if you are using a VPN, always use HTTPS where available.


Can someone please briefly explain HIPAA compliance?

HIPAA compliance is a little more complicated. There are minimum security standards with regards to configuration in the network, systems and physical security domains which must be met before your organization may be certified "HIPAA Compliant". There are too many to list here, but to give you an idea, here's a few line items.

On the network side, such minimum security standards include:

Separate VLAN for medical records / medical device traffic
Access Control Lists with default-deny, restricting access to medical VLAN
Default-deny access policies (users must be explicitly granted access)

On the systems side:

Workstations auto-lock their screens after X minutes (usually <15)
Users are required to change passwords every X days (usually 90)
Granular permissions for network shares, with default-deny

On the physical side:

Physical access to network/systems maintenance areas must be secured through lock & key at minimum, two-factor preferred
Security cameras must monitor building entrances and server/network rooms

On the administrative side:

Terminated employee credentials must be revoked same-day
Employee background checks must be conducted, by a vetted agency

...and the list goes on-and-on. That's just the tip of the iceberg.

Generally, the network/systems security requirements follow the NIST SCAP guides: security checklists of "best practices", which may be found here:

NOTE: Large parts of these websites are unavailable during the government shutdown.

EDITed to add:

In a legal sense, you'll need to ensure that you follow all the guidelines. This is the "due diligence" for HIPAA compliance. See here

Note that if the Department of Health & Human Services audits you and finds security compliance issues, your organization may find itself on the wrong side of more than one regulatory body.

EDIT 2: Also note that "certification" by a third party does not absolve the business entity from any responsibility relating to HIPAA compliance.


How to check if my ports are exposed to the internet

If you want to know what port is accessible from the internet you actually need to try to access the port from some place on the internet. There is no way to do this locally since it is unknown what firewalls, NAT etc might actually block the access.
You can be pretty sure that at most what is accessible from inside the local network is also accessible from the internet. But likely there is much less accessible since most machines are not connected directly to the wild internet but separated from the it using some NAT router or some firewall which implicitly or explicitly restrict what can be accessed.


Clarifications sought about SSL cert signing process

If you are asking can you use the same keypair, yes you can always use the same keypair.  Your first and second certs could have also used the same keypair.

If you mean will the CSR do a reissue instead of requiring you to purchase a new cert?  That isn't a technical question.  They certainly "can" but most will not.  Any change to the cert will require you purchasing a new cert.

You have a bigger problem however.  I don't think any CSR are still issuing certs using SHA-1 anymore.  While it may not matter for your purposes most browsers have deprecated SHA-1 certs so for compatibility reasons they will probably require for it to use SHA-256.


To know the strength of your password, don't look at its length, but at its potential. A password is as good as it is random, i.e. as good as the number of other values it could have assumed.

A simple case is when the password was generated as a sequence of random letters, each letter chosen uniformly and independently of the other letters. Since there are 26 letters, a 20-letter password implies 2620 = 19928148895209409152340197376 combinations. An attacker trying to guess the password will need, on average, to try half of them before hitting the right one. The accumulated cost would be tremendous, so the attacker would have very little chance of breaking through it. This number of possible, equiprobable combinations is often called entropy (not exactly the same notion as in physics, but close enough) and traditionally expressed in bits: you have an entropy of n bits if the number of equiprobable combinations is close to 2n. With 20 random letters, this means about 94 bits of entropy.

Moreover, TrueCrypt uses a good password hashing function, namely PBKDF2 with a random salt and 1000 (or 2000) iterations. Password hashing is a subtle matter, and TrueCrypt does it correctly.

To make the story short, if your password entropy is anywhere beyond 70 bits, your security is fine -- meaning that the cost of brute-forcing the password would far exceed the cost of simply obtaining the data through other means, such as abducting you and your family, or simply buying you out. We are talking about several (many) billions of dollars here... So, with random letters (all lowercase, let's make it simple to remember), 15 letters are enough. If you add uppercase letters and digits in the mix, 12 letters suffice, but the password may be harder to remember, and harder to type, especially on tablets/smartphones.

A crucial point of password generation is the need for good, impartial randomness. If you chose the password in your head, then it is not random. Witticism is not randomness; quite the opposite indeed. It is hard to estimate how much random can be a human-generated password, but it is often observed that such passwords are assumed by their owners to be a lot more random than is actually the case.

In the example above, I used letters but the calculation easily expands to any set of "symbols", even words. See this answer for details on a famous example.

The key files serve two purposes:

To provide some extra entropy to a weak password.
To provide some extra entropy which does not come in through the same path as the password.

Indeed, a poor password can be brute-forced if it does not have enough entropy, but even good passwords can be preyed upon through various methods: keyloggers, well-placed security cameras, sleep-talkers... Some of these methods will grab the password but not the key file, so the key file may save your skin in some situations.

The key file adds some security only insofar as the attacker does not know the file contents. However, it is a file. It is written on physical media. It is made available to the machine itself upon disk unlocking. We must assume that someone who steals the machine will also have a copy of all the files which could serve as key files (it depends on where you store them, but they are probably close to the machine since you need them to boot it). So the secrecy of the key file is not about the file contents, but about which file is used. For instance, if you have 100 possible files, then entropy is multiplied by 100 (in "bits" notation, this means about 6.6 extra bits). On the other hand, you have to remember which file was used, so that's some extra effort beyond the one needed for the password itself.

Personal opinions:

I note that key file processing in TrueCrypt is singularly homemade and weird; my cryptographer's senses are quite alarmed at this assembly of CRC-32 and haphazard scrambling. It would have been much simpler and better to simply hash each file, then hash the concatenation of the hashes and the password itself.

Also, the scenarios where key files have any value are rather restricted: these are scenarios where the attacker could grab the password, but not the key file, or not the information about which key file was used. For instance, a camera which has a view on the keyboard may also see your screen and easily obtain that information.

Therefore, I deem key files "not worth it" and I find that using the brain memory capacity to remember the key file to use is better employed at remembering a stronger (more random) password.


Two-way secure communication using two pairs of public/private keys?

This protocol is vulnerable to a replay attack.
In common notation

A -> I_B: {m}_PK(B)
I_A -> B: {m}_PK(B)
I_A -> B: {m}_PK(B)

If m was a message saying loan me $10 and B was a little naive ...

This protocol is also vulnerable to message reordering attacks e.g.

A -> I_B: {m}_PK(B)
A -> I_B: {m'}_PK(B)
I_A -> B: {m'}_PK(B)
I_A -> B: {m}_PK(B)

If we assume RSA, then if there is no padding then such a protocol would be weak to homomorphic encryption attacks.

Various other attacks are obvious but uninteresting (such as denial-of-service by the intruder blocking all messages, dictionary attacks letting the attacker verify a guess at the message, dictionary attacks letting the attacker detect repeat messages, message truncation attacks etc.)


Let me ask you a question.

Do you really think that your users will be able to remember the subdomain he should be using? I know that I most definitely will not.

So what happens when a user forgets what subdomain he should be using? Chances are he will try out a few of them to see if it works. This will trigger a lockout according to your scheme. Now, you have an angry user calling your support line screaming at you to fix things. An angry user is a careless user.

So what happens if an attacker sends said user a phishing link? After going through the annoying process of screaming at customer service a couple of times, the user will probably not question the fact that he is able to login the very first time through the phishing link. In fact, he will be quite happy.

So no, I don't think this is a good scheme as it has the likelihood of pissing off your users. When it comes to security, you really want users to be on your side.


How to leverage a stored XSS to perform a file inclusion?

XSS is an attack against the client, not the server.

The only way an attacker could turn this against the server is if the victim has special privileges (like an administrator account).


Are Skype drive-by attacks theoretically possible?

Although it is certainly theoretically possible that your system could be compromised by vulnerabilities in Skype and/or Windows 8,  there's no indication that your system was cracked in this case. It could have been a hacking attempt, or it could have been ordinary skype spam. I'd suggest you set Skype to prevent contacts or at least file transfers from non-contacts.

Amazon AWS is for the most part legit, a cracker would have to be pretty stupid to open an AWS account in their own name and be tracked. Besides, why pay for it when you can crack an insecure server and use it for free? AWS, like the rest of the servers out there is only as secure as the people maintaining it, if malicious traffic was coming from AWS it was most likely coming from a compromised legitimate site.


Is deleting files from a database considered a denial of service attack?

Yes, in the sense that anything which "denies service" is a "denial of service".

The CIA Triad defines information security as anything which affects Confidentiality, Integrity, or Availability of the system / data.

As pointed out in comments, this is not always an "attack" since it's just as likely to be accidental. Whether this is the result of a malicious attack, an admin botching a patch install, or the building catching fire, DoS due to data loss is definitely a security risk for which organizations should have a plan in place.

Assuming it is an intentional attack, if they have enough access to the backend server to delete db files, then there are far more subtle and nefarious things they could do (like stealing the db, selectively deleting data, planting a network sniffer, etc), so a DoS is pretty much the least dangerous thing in the category of "attacker has write-access to the server's filesystem", which is why "deleting the database" is to "DoS" as "canoe" is to "vehicle": not the first thing that comes to mind, but technically counts.


Machine readable, user non-readable - XML file

What you are talking about is not so much encryption as obfuscation. Obfuscation techniques are generally not considered part of cryptography.

XML is a data format and as such doesn't perform any processing by itself. Obviously it can contain elements that require processing but that processing is probably not Turing complete. That means that an encrypted XML file by itself cannot be interpreted by the EventGhost parser. Besides that, EventGhost can probably not be configured with a key, so that makes it impossible to use symmetric or asymmetric encryption techniques.

So what can you do with regards to obfuscation? Well, you can replace all the readable characters within the tags by escape codes. See the W3 XML specifications for more detail. But please don't call this cryptography or encryption. Google for XML obfuscation and you may find other resources.

If you want real crypto then you must be able to decrypt before the XML file is processed. XML-enc would of course come to mind.


How can I remotely wipe the contents of a Linux Laptop if its been stolen?

I've had a look and I think this question provides some interesting options. I'll summarise them here:

dd if=/dev/zero of=/dev/sdaX copies zeros over your whole disk. rm -rf --no-preserve-root / recursively deletes all files on a disk, overriding the rm -rf / warning on systems where that is enabled. If you can get to a box via ssh, running the dd variant should pretty effectively destroy your disk.
The grub option is interesting in that it gives you VNC access - however it would likely be obvious to the attacker that you're launching VNC - they'd need to hit the right grub option for starters! A hidden grub menu with the real launch entry might suffice... but we're talking about trickery.
This AskUbuntu question deals with this issue too, recommending a solution.

If you're prepared to do some work yourself, you could configure a very-early-stage init entry with sysvinit or whatever your system uses - check a url you control e.g. https://remotecheck.yourcompany.com and if the device is stolen, begin a wipe.

The ultimate problem with any remote wipe solution is invoking it - you need to be able to access the device. The reason I mention using a custom init-invoked job is that it is more likely you'll have access out than direct or known access in - i.e. if the attacker is behind a router at their base of operations, chances are good that outbound connections are allowed and much lower that they have an IP you can bind to and allow incoming connections on.

Of course, none of these solutions actually guarantee anything - if the attacker knows how they work they can just turn them off. A solution mentioned in comments is to use disk encryption, which will make the disk unreadable under these caveats:

the whole disk is encrypted - otherwise your software might write to unencrypted areas.
the system is powered off or for example luksSuspend -wipe has been run to remove the keys from memory.
the attacker has had no way to observe the key entry prior to stealing the device.

Honestly - I'd go with disk encryption.


HTTP Server: Response time on login request

Yes you should be concerned about this. Its a possible side-channel and it reveals information about your system.
Some possible defenses (that are being used) are:

Use a pseudo random minimum wait delay. (this means that a valid or invalid response will take about the same amount of time)
have an invalid response do all the calculation steps of a valid response (just with a invalid as return value). this is CPU intensive but often employed through ignorance. (the engineers just make everything go through all the steps)
Incremental Delay (each attempt doubles a delay factor) the iphone employes this for example.
Use a central authentication service that employs some defense against this. either through traffic or some other means.


"Memory-Hard" vs. "Memory-Bound" Functions?

To quote Wikipedia:

In cryptography, a memory hard function (MHF) is a function that costs significant amount of memory to evaluate. It is different from memory bound functions, the latter incurs cost by slowing down computation through memory latency. MHFs find their use as a form of proof-of-work.

In other words, Memory-Hard Functions require a specific amount of memory to evaluate them. Memory-Bound Functions do not specifically require a certain amount of memory, but their computational speed is dependent primarily on the memory available, in contrast to Compute-Bound Functions, where the computational speed is dependent on how fast you can calculate.

Does it mean that we have two different memory-based techniques?

Not really. Memory-Hard is a more desirable property when it comes to cryptography than Memory-Bound.

Why go for Memory-Hard Functions in the first place?

The reason for this being is that for any given algorithm, given a motivated enough actor, they can build a specialized ASIC that computes this algorithm fast and efficiently, in comparison to a CPU or a GPU. Memory, however, scales rather poorly still. Having an 8 GB large cache for an ASIC to ensure maximum performance is still not feasible, but the calculations can still be done on off-the-shelf hardware.
In the best possible case, you want an attacker with specialized, purpose-built hardware to have as little advantage over an off-the-shelf computer as possible. In other words, the only way for an attacker to attack you "faster" is to spend more money, not to spend the money "smarter".


How could hackers get access to directory after hacking Wordpress at LinuxMint.com?

Looks like was more a defacement: hackers changed the page with the downloads, pointing the links to another server where they hosted the tainted iso files. They didn't changed the iso files hosted on Mint servers:
A post on Mint Blog stats:

What happened?
Hackers made a modified Linux Mint ISO, with a backdoor in it, and managed to hack our website to point to it.


Is it possible to set up a second router with the same SSID to get the password?

No, unlike HTTP Basic authentication, the password isn't sent in cleartext (or obfuscated) form across the air.

The weakest form of WiFi security is WEP. Don't use it, it can be cracked, but not in the way you describe.

The password is used to create an encrypted tunnel as described here

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


Security implications of granting IIS user group folder modify permissions

It is perfectly normal for a website to need write access to one or more folders under it's web root. The AppPoolIdentity is the best thing to use for application pool identities as it does not create a windows user account that can be compromised. Instead it generates a new local user on the fly when the application pool is started. Granting the AppPoolIdentity write permission to the entire wwwroot would be my only concern. Instead you can just give it modify access to the particular logs or reports folder to minimize any sort of risk.

EDIT: Restricting write access mitigates any damage that could be caused by a compromised application. Write access to the entire wwwroot would give full access to rewrite entire site (if compromised) compared to if you only gave write permissions to the logs folder. They would have to compromise the OS/NTFS Permissions to get past that so it is an added layer of security.


Security of bluetooth tethering vs. wifi hotspot

As mentioned in the comments, WiFi is most definitely more secure, as long as you use WPA2. Do not configure your phone hotspot to open, or to use WEP, as one is completely without encryption, and the WEP is completely broken and has been for a long time.

Also make your password some random combination of numbers and letters, as you can still crack WPA2, if the password can be easily guessed, for example a short word. Using 16 characters of random numbers, letters and symbols makes this very hard on the other hand, since you just need to test every single possible password instead of just going through a dictionary.


What are some ways that an attacker could use a 301 or 404 http response?

Whether or not a 301 OR 404 HTTP/1.1 response to a malicious attackers
  POST or GET request actually stops them from 'posting' or 'getting'?

The "attacker" sends a post request to the server, the server receives the request and responds to it with a code and maybe some content.

For a 404 code for instance, it's a common practice to send an html page with the 404 error as well.

What the server does with the request upon receiving it depends on the server. If the POST request was to insert a record in a database the server could very well insert the record in the db and then reply with a 404.

It would be a crappy implementation, but it can certainly be done.

  Can these response codes inevitably help the attacker out?

Of course. The response usually contains headers with information about the server. Even if you disable the headers, the response can be used to obtain information about your server with fingerprinting techniques.

How helpful this information is will very much depend on context.

  Are there better ways to have servers response to external request
  (how?)?

I'm not sure what you're asking here. You can disable certain headers, try to fool fingerprinting software like nmap, and a myriad other measures that would change how the servers respond and maybe improve protection.

But you're going at it backwards. First define what the threat you're defending against is. Once you have that you can easily evaluate the effectiveness of the different protection measures.


Which algorithm is used to combine a key between client and server?

This is another variant on "How does TLS work?".

With Diffie Hellman, the shared secret that results from the exchange (g raised to the power of a raised to the power of b mod p) is fed into the PRF (together with other values) and is used to generate AES keys (and other values). The keys from the certificate do not participate in this process. Asymmetric authentication is achieved by doing a new online digital signature on the values of the DH key exchange using the private key for the certificate, which protects from MiTM attacks.

With the obsolete RSA key exchange (which does not provide PFS and does not exist in TLS1.3), the client just generated a random value, RSA-encrypted it to the public key from the certificate and sent that. The server RSA-decrypted the value using the private key for the certificate, thus establishing a shared secret value and at the same time proving possession of the private key from the certificate. This allows retroactive decryption of network intercepts after the private key for the certificate leaks (even if the certificate is already expired). The shared secret value is fed into the PRF, yada-yada.


Why is GPG-agent still caching my passphrase?

Solved the issue.
TL:DR GPG Suite was saving the password in macOS Keychain (not GPG Keychain)

More information here.


Regarding number of packets needed to crack WEP

Yes it does, but you have to take into consideration the probability of  collision not only size of key space.

As you said the key space for WEP is 224, with this key space there is a 50% collision after only 212 packets, so you don't actually need to go over the 224 packets to find a collision. After only 12430 frames you get 99% collision probability, so from there you can see that 224 key space is a really low number in order to secure WEP.

To go through the math you'll need to check out the Birthday attack which is uses the birthday paradox probabilistic model to reduce the complexity of finding a collision. It's actually pretty interesting to have a look at (it's also used in order to compute MD5 collisions). Basically it's based in the probability of finding 2 people that have the birthday in the same day in a set of N people randomly chosen.

As you can see probability reaches 100% with 367 persons since there are 366 possible birthdays but with only 23 people you get 50% chance of collision!

The problem is that WEP uses RC4 which is a steam cipher, that means that no cipher key can be reused. This would mean that BSS would need to change its cipher key as soon as all 224 keys have been consumed, but WEP protocol doesn't implement something like this.

WEP uses the same base key for all users so the security of WEP is based on never recycling a pair of [Base_Key,IV].

For the given scheme WEP would need an avoidance algorithm to avoid to different nodes to reuse the same IV, but again WEP doesn't implement something like this.

What WEP does is randomly selecting an IV from the 224 key space, and this is where the Birthday paradox comes into play.


Is SSL + DNScrypt enough to hide visited domains from my ISP?

DNSCrypt only protects the DNS lookup. The HTTPS connection is still made to the original target which thus reveals the target IP address to the ISP. And, if deep packet inspection is done the target hostname can also be extracted from the TLS handshake (SNI extension in ClientHello). This means the ISP can see which sites you visit but not the exact URL on this site. Although in case of well known public resources on the site traffic pattern might reveal too which of these resources you have accessed.


Checking for hardware vulnerabilities (like Intel Management Engine) semi-automated?

CHIPSEC is arguably the most comprehensive tool for analyzing firmware security to date.

The first answer provided resources for detecting whether or not INTEL-SA-00086 affects you. There is another, the CHIPSEC framework, which scans your BIOS/UEFI for various security issues and reports it to you. It is frequently updated in response to new information. From their Github page:

  CHIPSEC is a framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components. It includes a security test suite, tools for accessing various low level interfaces, and forensic capabilities. It can be run on Windows, Linux, Mac OS X and UEFI shell.

It is capable of providing information on various capabilities of your firmware, and whether or not it is configured to resist modification from software. There are many ways to overwrite firmware with privileged access, and your firmware has to lock itself down properly. Even missing one detail can result in firmware which can be modified at runtime. It can also provide details on specific vulnerabilities, and on more mild issues such as whether or not your keyboard buffer contains keystrokes entered while in the BIOS, which could disclose your BIOS password.

Note that CHIPSEC output can appear rather arcane at times. It is designed to be used as a framework by researchers and firmware vendors, so it does not go into detail about the implications of various issues it has found. The manual gives more details about the purpose of each module, and this page provides information on some of the more common modules and vulnerabilities. You can also expand its functionality by writing custom modules. It is a framework, after all.

Example output from the common.bios_wp module:

[+] imported chipsec.modules.common.bios_wp
[x][ =======================================================================
[x][ Module: BIOS Region Write Protection
[x][ =======================================================================
BIOS Control (BDF 0:31:0 + 0xDC) = 0x2A
[05]    SMM_BWP = 1 (SMM BIOS Write Protection)
[04]    TSS     = 0 (Top Swap Status)
[01]    BLE     = 1 (BIOS Lock Enable)
[00]    BIOSWE  = 0 (BIOS Write Enable)
[+] BIOS region write protection is enabled (writes restricted to SMM)
[*] BIOS Region: Base = 0x00500000, Limit = 0x00FFFFFF
SPI Protected Ranges
------------------------------------------------------------
PRx (offset) | Value    | Base     | Limit    | WP? | RP?
------------------------------------------------------------
PR0 (74)     | 00000000 | 00000000 | 00000000 | 0   | 0
PR1 (78)     | 8FFF0F40 | 00F40000 | 00FFF000 | 1   | 0
PR2 (7C)     | 8EDF0EB1 | 00EB1000 | 00EDF000 | 1   | 0
PR3 (80)     | 8EB00EB0 | 00EB0000 | 00EB0000 | 1   | 0
PR4 (84)     | 8EAF0C00 | 00C00000 | 00EAF000 | 1   | 0
[!] SPI protected ranges write-protect parts of BIOS region (other parts of BIOS can be modified)
[+] PASSED: BIOS is write protected


What would 'best practice' look like in protecting critical infrastructure against state actor cyber attack?

Warning, lots of text. Very complicated issue. tl;dr is: we as a nation are not doing much and have not been doing much. The current mentality is "it's up to businesses to fix it before the GOVT has to get involved." Companies don't want to pay, and don't know what to do, and don't see a "market motivator" (yeah, literally hear that all the time. I'm not kidding). Europe is doing much better with the push towards 62443 requirements for all ICS.

I'm primary on ICS/Critical Infrastructure for a company that is involved in the certification of security for devices associated with this. And I have bad news. there is not much requiring most infrastructure to secure itself. Nerc-CIP is related to power grid, but not everything has security requirements. Nuclear has some, through both NEC and IAEA and their overlap with Power Grid. Otherwise... not much.

Every year there are speeches at security conferences about how "squirrels" have done more damage to our infrastructure than hackers. That said, remember there is no honest disclosure rules for infrastructure. We don't really know how much is squirrels and how much is not.

I can tell you this though, as a first hand ICS pen tester who has worked with a slew of products in this space... at least 1/3 of -new- products come in the door critically vulnerable (in my experience. and I'm being generous), and only a very small percent in total have clearly been built with a full "defense in depth" security plan. Good news is when we are done with them they are way more secure and the companies we have worked with are developing better practices (if needed).

Also good news, there are good practices to secure insecure devices inside a network, even if the devices are not secure, but there are not a lot of constant audits and checks for this. In fact, my experience is the HIPPA, PCI, and SOX all have much firmer rules and accountability than securing Crit. Infrastructure. I'm also including 911 response systems in this, which have been shown to be vulnerable also.

There are a myriad of examples from the past 10 years, which really ramped up in the past 4, of nation state style attacks on Crit. Infrastrucutre. The Ukrainian power grid has been attacked multiple times using multiple tools, the thinking being it's a training ground for Russian hackers. The US gov't attacked nuclear facilities in Nitanez using custom malware in a very famous exploit back in 2010-ish. Lots more. Too much for this response.

As far as what's being done... not much. Companies can't afford millions of dollars of renovation, there are no universally agreed upon standards for modern secure ICS protocols (yes, most ICS network protocols are plain text with no verification of devices), ICS teams can't find security professionals who understand ICS because there are -very- few. There is a slew of other issues...

And it gets worse... I literally sat at lunch with the former head of DHS. It was me, him, 2 other people. He was deeply concerned as our current administration is leaving massive staffing holes and seems to be completely uninvested in any sort of push to fix this issue and secure the nation. Yes, it's true they have lots of DC conferences to talk about it... but no one is putting up the money or creating legislation.

The good news is that in general we know how to secure our systems and what are the major weakenesses at every level of the technology stack (from CWE's to Network zoning). ICS-CERT (a branch of US-CERT, the american emergency response team for cyber) has a great articles on it. Along with NIST, IEC 62443, and a smattering of others. Good place to start for anyone in ICS who is now concerned. Google search this are there are multiple, find the one best suits your needs:

[google] filetype:pdf ics-cert best practices