Is it dangerous to allow user to view a file directory via web browser?

It depends on what's in there.

Originally the idea behind the web was to provide a catalog of useful information; each file in a public directory contains some piece of information, and an index is automatically generated to make that information accessible. The whole reason why your default file is traditionally called index.html is because that file theoretically is supposed to be an index, just like the auto-generated one, but perhaps formatted differently.

If the directory contains nothing but publicly-accessible files (such as pictures, PDFs, HTML files, or what-have-you), then the auto-generated index is no less secure than an equivalent manually-generated index.

But if instead you have some sort of web app -- and particularly one written in PHP or ASP or ASP.NET or a similar language where the application files are stored inside  the document root mixed in with the media -- then the auto-generated index may provide links to files that you didn't intend to make public. This is even more true if you have "include" files in there as well. And in that case, this automatic index could make it easier to find files that could lead to a vulnerability.

Note that the index itself is not a vulnerability and is not a security risk in itself. Instead, it could assist in locating and exploiting some other security vulnerability on the site. If you have no such vulnerabilities, then the index does not add any risk on its own.

Furthermore, all of the practices that could make a directory index dangerous are, themselves, categorically bad practices, and are not made safe simply by removing the  index directive.

This specifically includes placing server-side code files in your document root. To be safe, you should have ONE file (index.php) inside your document root, and ALL the other files outside. Your index.php file should contain nothing but bootstrap code that loads and executes your webapp, while the webapp handles all URL routing independent of your filesystem structure. Aside from that, your document root should only contain static files that are safe for anyone to view.


I am not an expert on either the PDF spec or PDF readers, but I would guess the encryption / decryption key for a cipher like AES is derived from the password using a Password-Based Key Derivation Function such as PBKDF2, and that the password and key are only held in memory long enough to decrypt the document. After that you can zero out both the password and the key and only keep the decrypted document in memory.

... some googling later ...
According to this old article describing the behaviour in PDF 1.3 (Acrobat 4.x -- 1999), it does seem to be the case that the content encryption key is derived on the fly from the password. I'm sure the ciphers and key lengths have since been updated to something more modern, but I would guess that the general scheme is the same.

The encryption key is generated as follows:

Pad the user password out to 32 bytes, using a hardcoded
32-byte string:
28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
2E 2E 00 B6 D0 68 3E 80 2F 0C A9 FE 64 53 69 7A
If the user password is null, just use the entire padding
string.  (I.e., concatenate the user password and the padding
string and take the first 32 bytes.)

Append the hashed owner password (the /O entry above).

Append the permissions (the /P entry), treated as a four-byte
integer, LSB first.

Append the file identifier (the /ID entry from the trailer
dictionary).  This is an arbitrary string of bytes; Adobe
recommends that it be generated by MD5 hashing various pieces
of information about the document.

MD5 hash this string; the first 5 bytes of output are the
encryption key.  (This is a 40-bit key, presumably to meet US
export regulations.)


How can I prevent `am` from starting my activity?

Either do the actual security check in activity B or make G send on some kind of token to B in the Intent.

The token can be any random data generated at runtime. Since G and B share the same process they can easily get access to it, but other processes cannot (not without manual debugging).

But note all of these only make it difficult for users to use your app without the password. The user does control the binary and memory, so can bypass any protection you put in.


ip-10-80-XXX-XXX.eu-west-1.compute.internal:80 110.249.208.XXX - - [11/Dec/2013:10:27:17 +0000]
  "GET http://mn.sina.com.cn/news/xianchang/2012-06-07/212535.html HTTP/1.1" 200

They are fishing for an open HTTP proxy, and your 200 response code says they found one.

By operating an open proxy, you're enabling people to launch any number of web attacks through you; it's even worse if you don't include X-Forwarded-For headers with their source IP.  Do you really want to enable other people's (potentially harmful) activity with your web server?

If you must keep proxy functionality on the server and want to stop the abuse, at least configure it with one or more of:

HTTP Authentication
An IP ACL which limits proxied traffic to a trusted block of IPs (incorporating Shadur's comment)


How to define security requirements to ensure that developers... do not provide security by obscurity?

An example is the content scrambling system to prevent DVD's being copied. While the scrambling system was unknown, this worked. Then a teenager called Jon Lech Johansen figured it out, wrote DeCSS and it was broken.

As @GrahamLee points out, security mechanisms which need to be relied on must still work even when known about by the bad guys.

These days Cryptography provides security in so many applications, so it is critical that it be implemented correctly. Because the mathematics is beyond most people, there is one school of thought which advocates publishing the algorithms and letting people the world over try to find flaws. The upside - many eyes. The downside - if the algorithm is already implemented, an attacker may find a flaw and be able to use it, so doing this before implementation is very useful.

The other viewpoint is to hide the algorithm to prevent attackers knowing how it works - The problem with obscurity is that it has been proven time and time again that relying on security through obscurity fails because at some point the bad guys discover the secret.

Worth reading this post by Bruce Schneier - a well known opponent of security through obscurity, and the author of various crypto algorithms which have been tested by the community - as an example of where obscurity has worked, but only because criminals did not learn of the plan.

I don't know if it is possible to really answer the last part of your question without more context. For example, if this is for code developed by 3rd parties you could demand a code review, but what you could really look for is a 3rd party that publishes their algorithms / code etc as open source.


What alternatives do email services provide when an account is hacked?

Gmail provides you with an out-of-band channel when logging from an unrecognized device! you can enable this two factors authentication feature so that every time you try to log in you have to provide an additional confirmation code that you get either from a phone call or just a text message. neither Yahoo, nor hotmail has already implemented this yet


First step into pentesting Vaadin web application framework

There isn't anything brilliant for web application testing with web sockets. Last time I tried, ZAP (https://www.zaproxy.org/) offered a better alternative to burpsuite, but I know that portswigger have since improved this aspect.

Like any other web application, you need to worry about user input, requests to the server, responses, etc. Consider the same layers of implementation where vulnerabilities could exist in: configuration, authentication, access controls, session management, input validation...
https://owasp.org/www-project-web-security-testing-guide/stable/
https://owasp.org/www-project-top-ten/


Just a note, when Random UID is enabled on an EV1 it switches from 7-byte UID to 4-byte UID, with the first byte always being 0x80.

This means that you have only 24 bits of entropy. This should not matter however as by selecting Random UID, you should no longer care about the uniqueness or integrity of the UID that is received during anti-collision because it will always change.

Instead, you can retrieve the original 7-byte UID by calling the GetCardUID command.


PHP - Needing help to encrypt/hash a password for small application

A few points:

Passwords should be hashed, not encrypted. Encryption is reversible; somebody who shouldn't have access but can see the app's source code can find the encrypted password and its encryption key, decrypt the password, and thereby gain access. Hashes are one-way; you can't turn a hash digest back into the text that was hashed.

You'll ideally want a slow hash function (PBKDF2, bcrypt, scrypt, or argon2, in order of increasing security) because fast hashes can be brute-forced pretty easily with modern hardware.
You'll definitely want to use a salted hash (the algorithms above will expect or auto-generate a salt), as otherwise an attacker can use a rainbow table (or simply Google the hash digest) to find the password very quickly.

The system you describe is far too fragile. With every user of this system sharing one password, it will get leaked. Somebody will leave the company, or sign in from a compromised system, or leave it on a sticky note where they shouldn't, or send it over an insecure communication channel, or something. In other words, there's no very secure way to do what you're asking. You really should have per-user access control, and yes, that probably means a database.

You also lose meaningful logging ability when you don't differentiate between users. If somebody gets in and abuses the system, you can't know who did it because all logins look the same. Of course, in the snippet above, you don't have any logging at all...

You don't mention any kind of password brute-forcing protection, without which an external attacker can probably crack the password in, at worst, a few days of attempts.

There are correct ways to handle your scenario, but they all work differently than you're describing.

Restrict the internal site to intranet (corporate network) IP addresses, and require external users to be on a VPN.
Delegate authentication to your internal login authority. If you have an LDAP/Active Directory server, you can pass the authentication request through to it. In fact, if you use Active Directory and IIS (probably not, since PHP, but still), this is as simple as setting the app to require "Windows Authentication".
Delegate authentication to an external provider, if you use one. For example, if your company uses Google Suite, you can use Google SSO (Single Sign-On) and verify that the user has a company email address. You could also use an external authentication provider, such as Auth0.
I guarantee that it doesn't need to be hosted on your public domain, although without knowing why you think so I can't offer better approaches. Still, this scenario is exactly what intranet servers exist for, and they can talk to your public web server over back-end channels (or via CORS through the client) if needed.

More generally, the fact that you're asking this indicates that you probably shouldn't be trying to roll your own authentication system. Without knowing more about the scenario, I can't say exactly what the risks are, but I would be very surprised if you manage to account for them all with a system like this one. Security is hard; it's a much better idea to go with a proven system developed by people who know what they're doing.


Is the lack of https reason enough to abort form submission?

A first comment is that email is not secure anyway. Maybe it "feels" safer, but it actually is not. Nowadays, many mail relay systems will try, opportunistically, to activate some SSL when the mail hops from server to server. However, on a failure to establish the said SSL, the same servers will automatically degrade to non-SSL mode and send the email as cleartext; a consequence is that an attacker intent on eavesdropping on emails as they flow will not find it too hard to do: it just is a matter of sending the right fake packet at the right point to make the SSL fails, and force the machines to fallback to non-SSL mode.

Moreover, when servers exchange emails, they usually store a local copy on a physical medium. That's part of the SMTP protocol. In older days, reliability of emails was taken seriously, so the protocol mandates that a receiving server is not allowed to acknowledge reception of an email until it has committed it to a physical medium which would resist a power shortage (in programming terms, this means that the email was written to a file and a call to fsync() was made to ensure that the data is not merely cached in RAM).

The end result is that an email containing "personal details":

may be intercepted and spied upon by industrious attackers (rumour has it that intelligence agencies do it on a regular basis, which makes sense because that's what they are paid for -- but they most probably do it by making deals with the mail relay system owners, i.e. ISP);
will leave traces in many systems that you don't know, ready to be revealed by malice or incompetence of people working in network organizations that you don't know of;

from which we conclude that sending the said details over plain HTTP may be a better deal in the long run. At least, HTTP traffic goes through routers which do not have a legitimate reason to store the packets on hard disks, and indeed honest routers will not indulge in such leaking.

Now a more important point is that HTTP, HTTPS, email... are just for data in transit. If you fear for the privacy of your personal data, then your biggest worry should not be that transfer operation. The real issue is that you are, by definition, sending your CV to some hiring agency that you don't know. You cannot be sure that they will keep it in a secure place and take care of it. Actually, given the average level of security awareness, it is a rather safe bet that your CV will be put on some hackable server, copied into multiple places, exchanged by emails and thus copied into multiple mailboxes of many people, and probably printed two or three times with copies ending up in totally non-secured dumpsters.

In that sense, the lack of HTTPS is not a good reason to abort the sending process, because HTTPS would not noticeably improve the overall picture anyway.

A more practical strategy is to consider that the "personal details" you put in your CV are not, in fact, private data. These will be shared with several (many) prospective employers anyway; a secret which is shared with many people is no longer a secret. Just accept it; review your CV and what you input in the form under the basis that it won't be private. In any case, people who really want to know your name, date of birth and list of diplomas already know them (for instance, it makes no sense for me to hide my birth date, since it appears in at least two places in the Journal Officiel, the official publication place for publishing laws and decrees in France). Also, 500 million people reveal a lot more about their lives on Facebook, and this (to my darwinian dismay) has not proved utterly deleterious to their well-being.

The best that you can hope to achieve is to avoid your personal details to be harvested automatically by mindless Web crawlers. For that, email, HTTP and HTTPS are all good enough -- and irrelevant.


The following is purely from memory and I have not checked to be able to provide a reference, but I seem to recall that the NoLMHash registry key prevents generation of LMhashes does not remove them.

The implication being NoLMHash is only 'effective' in a practical sense after an account password change, until then both hash types will persist.


apt-get update
apt-get upgrade

If you are on Windows or OSX just enable "check for updates" in any important programs. All the ones I use have that option. Also, you don't need to update those "200" programs. I would say update any text editors, PDF viewers, antivirus etc. Some antivirus clients can alert you to updates to some programs as well.

Check out this article for other suggestions. http://lifehacker.com/5384140/five-best-software-update-tools


Handshake failure with identical client hellos

This could be the action of a Network Intrusion Detection System, like snort, that has found some reason to refuse to allow one of the systems to connect.

NIDS systems work by sniffing all the packets on the network, identifying those that may be associated with suspicious behavior (such as a port scan), and then responding in some way.  By default, most NIDS will just write an alert in the log if they see something.  But your network team might have gotten more aggressive, at which point they may have enabled "active disruption".

Let's say that the failing box was used to do a network scan, and your NIDS caught it.  It would record that IP address, and every time it sees a packet on the network associated with that IP address, it sends a forged RST packet to it that looks like it came from the server's IP address.  That would prevent the machine from connecting to the server, which would certainly stop an attack.

I recommend engaging your organization's network security team, and see if they have any record of the failing machine's IP address being caught by their NIDS.


What can schools see on school issued Mac?

Supply chain interdiction is thought to be a capability only reachable for APTs. I doubt your school has the capability to do this, unless they have a basement with a bunch of hairdryers and shrink wrap...

If they did, than a bunch of files on the file system would have been created or modified. A recursive search for all executables sorted by modified should show you if some executables have timestamps that stand out form those installed with the original image. If you’re interested in what command could show that info leave a comment. That would be a separate question but I’d help you figure it out.

However, last time I checked it was free to reinstall the OS on Mac devices. If you’re like me you reinstall everything from bare metal. https://support.apple.com/guide/mac-help/reinstall-macos-mchlp1599/mac

It sounds like you are aware the school could inspect anything you do on their network and email services. That is correct. You should not have an expectation of privacy when using their services. You may want to set your iOS devices to sync via the USB cable to prevent sync over LAN. Tunneling protocols could help, but that’s getting into another subject.

Maybe review the paperwork you signed when you completed orientation... If your school is wiretapping communications to students by deceptively handing out computers ladened with spyware... or intercepting communications between syncing devices... That would be quite a news story.


Why are DSA keys referred to as DSS keys when used with SSH?

DSS is simply a document that describes the signing procedure and specifies certain standards. The original document is FIPS 186 and latest revision in 2013 is FIPS 186-4. DSS is a standard for digital signing.

DSA is a cryptographic algorithm that generates keys, signs data, and verifies signatures. DSA, in itself, can use any hash function for its internal "cryptomagic", and it can also use any (L, N) for its parameters' length. DSS, as a standard, defines DSA's optional specifications.

DSS says that DSA should use SHA-1 as its hash function (recently, SHA-2). DSS says that DSA should use specific length pairs such as (2048,224), (3072,256), etc.

When SSH says DSS, they mean that they're implementing DSA in compliance with the DSS.


"Community Name" are used in SNMP v1 and v2 as an authentication asset: one presenting the good "Community Name" in his request will be authorized to get/set informations.

That's probably why people call this "default password" ...


Is there a functional difference between `chage -M 99999`and `chage -M -1`on Linux?

chage -M 99999: The password will be valid for 99999 days (until 21 feb 2290 if changed today)

chage -M -1: This will remove the checking of the password's validity.

So, unless your users are quite longlived (and are not going to change your systems passwords)… no, I don't see any functional difference ☺

That security scan doesn't seem too thorough.


Script kiddies need holidays too.
Seriously, how about the answer "coincidence"? If there are usually one or two per day, it´s not that hard to believe that some days have 0. Just random background noise in the internet.

Or maybe there was a single person repeatedly trying to get into your net. In this case, things happen to people. Computer broke; hospital, drinking the whole day because girlfriend left...

Or maybe someone got into your net and thought it would be a good idea to delete the log.
Maybe. If the missing attack is the only problem, I wouldn´t panic. If it lets you sleep better, check some more things, and if everything is ok, forget it.


Verifying that a user is from a certain country

I don't think that you are going to find a free and effective way to do this that doesn't expose your users to privacy issues.

For instance, I just moved to a new country. I have a phone, drivers licenses, accounts, and IDs in both countries. I sign up for services limited to residents of these countries. There is no way for any of these services to know for sure where I really am.

One way to increase the assurance is to get copies of your users' national documents: birth certificates, national ID cards. But then you will have to deal with the fact that you have these sensitive documents and the privacy issues they expose.

At best, you will be able to determine that someone was able to sign up for services in a particular country, and that's it. You will have to decide if that's enough for your organisation.


Data visible when intercepting traffic even though SSL is used

Its because the API destination cannot be hidden by SSL.
Whats hidden by SSL, is the data, eg the request and response, including the path part of URL.

So out of this url: https://www.example.org/search.php?sdata=somedata
the following will be encrypted: /search.php?sdata=somedata
the first part, https://www.example.org, will NOT be encrypted (read more why not).

Whats not hidden, is the destination IP and destination port. Furthermore, the DNS request immediately preceding this, is sent in the clear.

A sniffer, can detect the caonical name of the destination in 2 ways:

Either, it can remember previous sniffed DNS responses, so if you previously did a DNS lookup for lets say api.example.org and got a IP of "8.8.4.4", the sniffer can then replace all occurences of 8.8.4.4 later with api.example.org

Or, it can do a so called rDNS or reverse DNS lookup. This means you do a lookup for a PTR record for the IP in reverse, so the rDNS of 8.8.4.4 can be found at a PTR for 4.4.8.8.in-addr.arpa which results in google-public-dns-b.google.com, thus the sniffer can replace all occurences of 8.8.4.4 with google-public-dns-b.google.com

Since you only can see the API destionation for some of the traffic, I suspect its the first case that is valid here, because if you did the DNS lookup prior to running the sniffer, this lookup is then cached for a period in your phone, which means that if the server in question lacks a rDNS value, the sniffer will normally display a IP instead of caonical name, which can give the apperance that some destinations are "encrypted" when they really are not.

If you want to hide the API destination from sniffing, you have to use some sort of proxy or VPN, where the traffic between the client and proxy/VPN is encrypted.


Guidance for implementors of HTTPS-only sites (Server side)

The main ones are:

Use SSL sitewide. Don't offer anything over http.  Instead, any connection via http should immediately redirect to the main site's landing page via https.
Use HTTPS Strict Transport Security. This will tell users' browsers: please, only connect to me over https.  This defends against sslstrip and similar man-in-the-middle attacks.
Set the secure flag on all cookies.  This will ensure that the cookies will only be sent over a https channel, never over an insecure http link.
Avoid third-party active content served over http.  Don't load external active content over http.  Make sure that any CSS, Javascript, widgets, analytics, or ads that you load from third-party sources are loaded over https.

Potentially better yet, you can consider making your own copy and serving these resources from your own server if possible, so you don't need to load them from a third-party source.  In many cases you can avoid loading CSS, Javascript libraries, or widgets from third-party sources simply by storing a copy on your own server.
For analytics, note that Google Analytics does support https.
Ads are the hardest part.  If you use ads, you may not have any choice but to accept third-party ads over http, which is a security risk.  If you do, serve the ads in an iframe (do not use SCRIPT SRC to integrate the ads into your page).

It is OK to load images hosted on a third-party host as long as they are loaded over HTTPS (to avoid mixed-content warnings).

I think if you do these four things, you'll cover most of the issues.  The rest are details that can be evaluated on a site-specific basis, but they are probably secondary in importance (in my opinion).

If you want to get fancy, you can look at certificate pinning and similar emerging technology, but starting with the above four is already a significant enough project.


Intercepting TCP traffic through MITM attack

I've set my default Firefox proxy to 127.0.0.1:8081

You shouldn't do that, the -p argument is there to specify where the Burp proxy is running.

  when I navigate to example.com

It doesn't matter where in particular you navigate (though google.com probably wouldn't work because of strict transport security). All requests targeting the port 80/tcp would be intercepted with the script and routed to example.com through Burp proxy.

Note that you may be running something on your port 80 already. I suggest changing the port number, e.g. to tcp:81:example.com:80, and try navigating to 127.0.0.1:81 to see if it works this way. If the port 81 works and port 80 doesn't, try using ss or netstat to figure out which program is taking over the port 80.

  Also this is not an HTTPS request, so I've generated
  my server.pem and server.key

You don't need them for HTTP requests.

  How can I intercept any domain TCP request on port 80?

I don't think this tool is generally well suitable for this task.

You can do it only by setting up a real proxy (like Squid) somewhere on your machine. The -l argument controls what resource do you intercept. The -r argument only controls:

The port
Where do you forward traffic.

In order for your requests to be handled by the target domain you need a proxy under the -r argument.

  What's an example command of intercepting SSL data (like HTTPS) through that script with those generated certificate files?

sudo python mitm_relay.py -l 0.0.0.0 -p 127.0.0.1:8081 -r tcp:443:example.com:443 -c server.pem -k server.key

Note that your browser would display a warning that the connection is untrusted, and google.com inevitably wouldn't work in Chrome. Firefox would be okay as of 12 April, 2020 — though this particular part of the answer probably won't age well.


File upload functionality - cer format verification

TLDR: 'PEM' format only uses the part between dashed BEGIN and END lines

The so-called PEM format used by lots of crypto software has evolved somewhat over time and isn't entirely standard. RFC7468 (in 2015) documents and describes some of the variations for some data types, including (X.509/PKIX) certificate. I often call this format PEM-style rather than PEM to emphasize the difference.

The core of the PEM-style format was and is that arbitrary (potentially binary) data is base64 encoded, broken into lines, and surrounded by -----BEGIN x---- and -----END x----- lines where x specifies the type of data. (OpenPGP 'armor' is the same except it also adds a base64 checksum.) In its original application to email, PEM needed to and did allow other data before, after and between PEM block(s). In the more recent adaptations of this format, some software does allow such external data and some does not or not always, but when external data is allowed it never affects the PEM object, which is always only the part between BEGIN and END lines; what the software does when external data is present but not allowed is not standard.

Changing anything in the data between the BEGIN and END lines, in a way that is it still valid base64, does change the represented data. An arbitrary change is likely to produce data that is not valid ASN.1 DER, and thus not any certificate at all. A carefully crafted change, including a malicious one, can produce data that is the valid encoding of some certificate, but generally not a valid certificate. Depending on exactly what validation is done this may or may not be detected.

Some (many?) applications that process certificates also accept the DER/binary representation from a file, but I'd expect a web or GUI application is less likely to because binary data generally can't be cut&pasted correctly. These files contain only smatterings of text and cannot be reliably identified, much less validated, by normal tools like cat or more or a text editor.


First of all,  this attack will not work on the latest 5.3 branch because null byte poisoning attacks have been fixed for file-io functions.   That being said none of your settings will defend against these attacks except for magic_qutoes_gpc in some edge cases because the null byte will be escaped.  Although to be honest I would disable magic_qutoes_gpc,  you should not rely upon it for security and more often than not it will malform user input.  magic_quotes_gpc is being removed in php6.

To make sure php is configured properly you should run PHPSecInfo.  You should also remove the write bit from your entire web root,  and remove file_privs from your mysql account.  Here is more information for locking down php.


Can name and date of birth be hashed somehow to generate a secure identifier?

If you don't trust the third-party providing the opportunity to access the internet at the login stage, you should not trust at any stage. They can save any data entered, including data related to facial recognition. Also they can store any data that you users receive from your server. The risk of such misuse is high, because such data cost money.

Brute-forcing of NAME + SCRAMBLED_DOB + SALT is trivial, because the number of births dates is very small. To represent all possible birth dates in the last 100 years only 15 bits are needed. If you have 1 000 000 people in your database, this would mean just 20 bit. This is 35 bits in total. This means, your database can be easily brute-forced. You can slow it down by using Argon2 or similar instead of SHA256. But it will be still too easy to brute-force. The reason is, that possible secrets are not random, they are very easy to guess.

In case somebody is interested in decrypting data of particular person, it is even more simple. Such decryption can be done immediately, without any brute-forcing.

Your words until a hash contained in the database is found mean that you are going to store hashes in your database. This makes brute-forcing even easier. An attacker doesn't even need to search through different births dates, through names. Instead, the attacker will just take hashes that you store and will just iterate them and will easily find what hashes to what encrypted data are used.

What should you care about? There are many points. Here are some:

Make sure that connection from user to your system is secure. If it is not secure, soon or later there will be people or companies, that misuse that and will collect data about your users. You will cheat users if your will not explain that to them. Also requesting some kinds of information via insecure channels can be a legal problem even in many developing countries.
Any measures like encrypting data in your database make little sense if communication channel is not secure.
Establish reliable authentication. Many people in developing countries have mobile phones. That's why besides passwords consider sending one-time password per SMS.


Does Cloudflare's DNS over TLS (DoT) implement DNSSEC too?

Your question illustrates a wrong assumption.
But before going further on that point, DoH/DoT secures the data in transit, while DNSSEC secures the data at rest. Both are orthogonal and I would posit that a good provider, offering multiple transports, should be able to offer DNSSEC on all of them (or none) because it makes no difference on his side (the computations he has to do for DNSSEC validations do not depend if the original client asked the question over plain UDP/TCP, or over HTTPS or over TLS).
Now back to what I think is a false assumption.
You are comparing:

using provider X to do DNS resolution on your behalf using "plain DNS"
using same provider but with DNS over TLS.

And you want the properties of DNSSEC. I am using "provider X" because the below is the same for any kind of provider.
The differences between the two cases is that with DNS over TLS, you have the guarantee (if everything configured properly both on your end and your provider's  end) that what you receive was not tampered with (nor listened to in fact) by any actor on the network path between you and the provider. It does not add any guarantee at all on what happens at the provider or what happens when the provider itself queries other nameservers to do the full resolution on your behalf.
Which means, about DNSSEC, that in this setup you fully accept what the provider will tell you. If it flips the flag saying "authenticated" you will believe that it did do the DNSSEC checks as needed and guarantees you everything clicks.
But isn't that a big assumption? Do you trust your provider for that, in all cases? Does it uses any filtering or any "Negative Trust Anchors" (which are used to bypass DNSSEC configuration errors, but could as well be used to bypass proper DNSSEC resolution, so if they are not solidly documented, and even better until noone does the equivalent of Certificate Transparency Logs for DNSSEC, you have really no guarantee what happens).
Etc.
Said differently: if you are really serious on your DNS setup you might want to bring another option to the table and study it (not saying it is a solution for all cases, just saying: please remember this option and judge it relatively to others). Which is: do the DNSSEC checks on YOUR side, not on provider side.
Any decent nameserver software can do it. Of course, this can still be thwarted by a rogue provider, if it starts to strip off root DNSKEY and things like that. But until that it may be a better security for you than relying on any provider do DNSSEC on your behalf.
PS: you are asking for links but note that this Q&A site does not want to be just a list of links, you have search engines for that; the aim is to collect knowledge here, not under some links that can go stale at any point. Also, since you cater for only one specific provider in your question, did you do the first step of contacting it with your question?


How to understand "Multiple Handshake Message" in TLS message type?

I assume you mean "when will Multiple Handshake Messages appear?"

That simply indicates that multiple TLS handshake messages (server_hello and certificate in this case) showed up in the same packet.

Wireshark puts that there to indicate to you, the viewer, that there are multiple distinct handshake messages to be reviewed.  It is to prevent you from looking at the top of the packet, saying "Oh, I don't care about server_hello, I'm going to keep looking at the next packet to find the certificate" without realizing they're both there.

Put differently, "Multiple Handshake Messages" isn't a TLS message type, it doesn't correspond to any bit set in the TLS packet itself, it's meta-information - a conclusion about the packet - being noted by the tool displaying the packet.


SANS first ran an article on the basics of what you are looking for -- a way to detect mimikatz on the network -- https://isc.sans.edu/diary/Detecting+Mimikatz+Use+On+Your+Network/19311/

However, remember that mimikatz is capable of Kerberos attacks --
https://dfir-blog.com/2015/12/13/protecting-windows-networks-kerberos-attacks/ -- as well as PtH attacks -- https://dfir-blog.com/2015/11/08/protecting-windows-networks-defeating-pass-the-hash/

More on the theory behind the Kereberos attacks is available from Microsoft, including their recommendations for detection -- https://www.blackhat.com/docs/eu-15/materials/eu-15-Beery-Watching-The-Watchdog-Protecting-Kerberos-Authentication-With-Network-Monitoring.pdf

This site also had some interesting log analysis techniques that I had not seen before -- http://securitynik.blogspot.com/2016/03/learning-about-mimikatz-skeletonkey_96.html

Finally, a good defense will also include some mitigation and prevention -- https://jimshaver.net/2016/02/14/defending-against-mimikatz/ -- however, remember that mimikatz has been rewritten in GoLang and Powershell, so your mileage may vary when trying to prevent a well-informed attacker.


How does WPA2-Enterprise protect against an evil twin attack?

I assume the question is about the "server" certificates used by PEAP, EAP-TLS, and EAP-TTLS to protect password authentication, as this wouldn't be a problem at all with client-certificate-based EAP-TLS.

I doubt the EAP standards documents would ever have this information, given the crazy inconsistency across implementations (which surely wouldn't be as bad otherwise). Also consider that EAP and 802.1X were used by Ethernet and PPP dial-up a long time before WiFi, so the standards likely wouldn't talk about SSIDs.

Update: RFC 7593 ("eduroam") was published recently and discusses this in more detail. eduroam is probably the largest service using 802.1X/EAP, with many federated realms worldwide. Its summary in RFC 7593, especially section 7.1, talks a bit about the situation of server verification among eduroam users.

  What information does the certificate that the AP sends to the client, contain: is it the SSID, or something else?

The PEAPv0 draft does not talk about this at all.

The PEAPv1 draft says:
"The peer SHOULD verify the validity of the EAP server
certificate, and SHOULD also examine the EAP server name presented in
the certificate, in order to determine whether the EAP server can be
trusted."

It doesn't however describe how the server name should be verified, and in fact admits that the name could be wrong:
"Please note that in the case where the EAP authentication is
remoted, the EAP server will not reside on the same machine as the
authenticator, and therefore the name in the EAP server's certificate
cannot be expected to match that of the intended destination. In this
case, a more appropriate test might be whether the EAP server's
certificate is signed by a CA controlling the intended destination and
whether the EAP server exists within a target sub-domain."

RFC 5281, which specifies EAP-TTLS, requires verification against a known CA, plus checking that it has the "server authentication" extendedKeyUsage enabled.

(Note that even the CA checking isn't always implemented; for example, iOS and Windows 8.1 ask the user to verify the certificate fingerprint when connecting for the first time.

The EAP-TTLS specification doesn't require any common-name or subjectAltName value as far as I can see. Some clients (Windows, wpa_supplicant) have a configuration setting for what the expected "common name" should be, while others don't care at all.

Note that the certificate isn't always sent by the AP, but often by the RADIUS server handling the authentication. There are federations like eduroam, which use the same SSID everywhere (some places even offer eduroam-authenticated Ethernet ports), but all authentication requests are routed to home organizations based on the @domain in the login name, and each organization has its own EAP certificate. So in a better world, the @domain is what should be compared against the certificate.

For example, Microsoft KB 814394 documents the requirements the Windows PEAP client has.

  How can the user know that it is connected to a trusted AP? Again, with HTTPS, my browser will give a warning. Will my PC or mobile device warn me if I'm connecting to an untrusted access point? Or is the only way to notice that there is something wrong the simple fact that one has to re-enter his/her credentials?

Depending on the client, you'll have some combination of the following checks:

fingerprint remembered on first use (seen on iOS, Windows 8.1)
common name checked against a configured value
issuer checked against a whitelist, which usually contains only the organization's internal authority (using a public CA is secure only as long as the common name is checked)

From my experience, the mismatches are shown practically the same way as authentication errors; only wpa_supplicant can be made more verbose.

Since many clients have CA verification as the only option, the only possible secure mode is verifying the EAP certificate against a dedicated CA for the organization. (If your EAP certificate is from Thawte, and clients can be configured to require a Thawte-issued certificate but don't do any subject/CN checks, then literally anyone could buy a regular SSL certificate from Thawte and use it on a fake AP...)

Unfortunately, if the client has an option to accept everything, pretty much everyone will use it, since installing a new CA is painful. (Not to mention that it often also allows the organization to spoof HTTPS sites, which is not very desirable, and even causes a permanent warning icon on Android.)

The eduroam network has tried to make this simpler by providing a standard setup tool and iOS profiles, but only a small part actually uses it.

As a result, you might never notice that something is wrong.


What techniques and tools do you use to relate security events?

Enterprise tools which correlate related security and logs events are generally called Security Information and Event Management (SIEM) systems. Most are designed to accept data from common log formats, IDS alerts, antivirus, firewall rule changes etc.

LogRhythm
http://www.logrhythm.com
Used by many companies around the world.
IBM QRadar
http://www-03.ibm.com/software/products/en/qradar-siem
Cisco MARS
http://www.cisco.com/c/en/us/products/security/security-monitoring-analysis-response-system/index.html
Intel McAfee NitroSecurity
http://www.mcafee.com/
ArcSight(purchased by HP)
http://www.arcsight.com/
Very expensive. It's a beast to setup, a beast to use, but the correlation engine is really impressive. A few years ago when I used it, it was able to correlate multi-stage attacks (ie trojan on host a, allows host b to be reachable to external ip, and also know host b firewall rule allows snort attack seen on IDS c to occur.
Looking at arcsight express (and asking my vendor for the price), it may be a nice fit for smaller shops (under 500 hosts) but it needs to be backed up by people able to interpret and analyze alerts.

Other tools that I know about:

OSSIM, The Open Source SIEM
http://sourceforge.net/projects/os-sim/
One of my interns has played around with this, with generally favorable reviews. For a project, or a small shop, this is probably your best bet.
Intellitactics (aparrently now owned by trustwave)  http://www.intellitactics.com/int/
They were another big player when SEIM first started, they were unique in that they were using a text database (as opposed to Oracle like ArcSight and the rest). I heard they were going to stop using a text db and move to something else, but never heard anything from then in a long while.
RSA enVision
http://www.rsa.com/node.aspx?id=3170
This was regarded as a pile of crap, talking to the new product manager of the team at defcon, they were re-banging the product, using business intelligence tools and techniques (column store databases, etc). What I was told was EMC (the parent company of RSA) bought Greenplum (a ZFS based BI system) for this project. I would be watching them closely, and maybe get under an NDA and get the real story.

I'm using older information here, would love to hear whats correct and whats not.


ELI5 why plausible deniability doesn't work in reality

Assuming I understand the question correctly, you are asking if have an encrypted hidden partition on your device would be a good strategy for information hiding when the attacker is restricted by the bounds of the law, which can force you to decrypt the information, but only if they find it.

To me, this sounds like security through obscurity. It is the equivalent of having the information in a hidden folder with an innocuous name. If discovered they can force you to decrypt it so the encrypted part of it is entirely irrelevant. All they need to do it discover it.

Security through obscurity is a bad idea if you are looking for a truly secure way to store your information, but it would obviously make it take more effort to find the information. However, with security you must always assume as close to the worst as practical, so you would need to assume that they find it, but without a better option it may be better than nothing.

Note: In regards to the plausible deniability portion of your question, this sounds like a legal question about whether this would be considered intent to hinder the investigation (or whatever the legal terminology would be) and is outside the scope of this site.


How to verify internet access restricted

You still need internal network access, correct?  There are lots of ways to be confident the system has no general Internet access but no way to PROVE it.  (If it is networked it can be tunneled, etc.)  You could programatically verify there is no default route for IPv4 or IPv6 - Only routes for your internal networks.  It's basic but easy to script.

If the problem you are trying to solve is making sure the network firewall admins did not open up outbound Internet access from your DMZ, you will need to do active testing against an outside (AWS or other hosted machine) with a combo if scripted NMAP blasting out from the machine you are testing and a deny all firewall on the AWS/hosted sensor machine with logging.  You will need to know what source IP the machine being tested is coming from.  Since it should have no Internet access, you can't just script in a "canihazip" check.


List of social engineering hacks and defenses

The book and methods mentioned in This Thread cover a lot of social engineering techniques. The book is written by Kevin Mitnick, a renowned hacker who now shares his expertise.

The book is pretty dated now, but because social engineering relies on human nature a lot of it is still relevant. This Book is also worth reading, and is more up-to-date, but the basic ideas remain the same.


Layer7 DDoS Protection vs WAF, which should I use?

1.What is other Layer7 DDos attacks, e.g FTP, DNS ?

Application layer attacks or layer 7 (L7) DDoS attacks refer to a type
of malicious behavior designed to target the “top” layer in the OSI
model where common internet requests such as HTTP GET and HTTP POST
occur. These layer 7 attacks, in contrast to network layer attacks
such as DNS Amplification, are particularly effective due to their
consumption of server resources in addition to network resources.

2.If I use WAF instead of Layer7 ddos protection, what will be risks in my system?
WAF can mitigate ddos attack in under certain level. Application layer ddos attacks are very difficult to avoid. Specially bot net attacks are not spoofed and request seems to be fully legitimate.
3.Using WAF for ddos protection is a prefered way?
You have to use adaptive technology like a captcha code. Because botnet attacks are very difficult to identified from legitimate traffic therefore captcha will be best solution.
Web application Firewall also option. Please Read link.
(Details copied from cloudflare)


What is the Digests section in cryptsetup

TLDR;
So, technically from this set of output, we can observe that :
" cryptsetup() is using LUKS2 and LUKS2 is using Argon2i as a Key Derivation Function.
Now, this Argon2i implementation might be using HMAC as PRF and that HMAC is using SHA256 as an underlying hashing function."
MORE ON IT -
A Key Derivation Function  (eg. PBKDF2, ARGON2, etc.) is generally a high-level function that needs to work with an underlying PRF (Pseudo-Random Function) and generally, it's HMAC (Hash-based Message Authentication Code).
It's not mandatory to use HMAC but generally, it is used with some Modern KDFs.
Now HMAC needs an underlying Hash Function to work and in this case, it's SHA256.
So it's like when they say "PBKDF2 with SHA256" they are saying "We use PBKDF2 which uses HMAC as Pseudo-Random Function and HMAC uses SHA256 as the underlying hashing function in it"
This theory works with most of the Modern KDFs.
Now when you look at the output again, see it as follows:
*Digests:
  0: pbkdf2
    Hash:       sha256
    Iterations: 104492*

The above output tells us the properties of the PBKDF2 function (or Argon2i in this case). notice 0:pbkdf2.
The next output,
Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2i

This tells us properties of LUKS2 (Linux Unified Key Setup) notice 0:luks2, which means LUKS2 is using key derivation function - argon2i.
Also, Argon2 is a KDF.
Argon2i is optimized to resist side-channel attacks. It accesses the memory array in a password independent order.[wiki]
LUKS1 defaults to PBKDF2 while LUKS2 support Argon2i.
PBKDF2 for LUKS1 (LUKS1 header format is limiting)
Argon2i for LUKS2 (LUKS2 comes with a new header format)

*More Resources :*
PBKDF2 : https://en.wikipedia.org/wiki/PBKDF2 | https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf | https://www.ietf.org/rfc/rfc2898.txt
HMAC:  https://en.wikipedia.org/wiki/HMAC | https://www.ietf.org/rfc/rfc2104.txt
LUKS: https://guardianproject.info/archive/luks/ | https://access.redhat.com/solutions/100463
ARGON2: https://en.wikipedia.org/wiki/Argon2 | https://www.cryptolux.org/images/0/0d/Argon2.pdf
Somewhat HMAC Related Stack* Question :
https://crypto.stackexchange.com/questions/35275/whats-the-difference-between-pbkdf-and-sha-and-why-use-them-together
I hope this helps. Please comment below for clarification on any point if needed.


Safer way to access paypal, Mobile or Pc?

There has been some questions about Nokia phones and how they handled SSL; namely, that up to recently the data was intercepted and decrypted on some servers owned by Nokia. While in this specific case they were probably doing it for the explicit purpose of adding compression and not at all for stealing cookies and passwords, this highlights the fact that a lot of things can occur within the guts of your mobile phone that you have very few ways of knowing about. Compared to that, a desktop PC is rather "open".

If you really worry about your PC, I suggest that, for bank-browsing, you reboot on a Linux LiveCD. Linux is rather robust against virus and malware, especially when used only for connections to "safe sites" and running off a read-only DVD.

One might notice that "rebooting off a DVD" is one of the things you can do with a PC and not with a smartphone.


Nemesis packets not detected in wireshark/tcpdump

Okay with my first test, I used etherape GUI to show what types of packets were being sent when I replayed the injected packet. What I saw was the color code for "UDP UNKNOWN" which leads me to believe it is a possible issue with Nemesis itself. In wireshark, there was no response from my router as a result of replaying the packet.

Subsequent tests using specific filters in wireshark as well as tcpdump are still showing zero results after replaying injected packet. I read over the nemesis changelog and it seems it has had injection issues in the past.

May have to report this as a bug in Nemesis even though I am not sure if the tool is even being maintained any longer. hate to say it but I don't think I'll be able to figure this one out. And that sucks.


I feel like I had the same issue but managed to get it working in my case. The module with the overflow had DEP enabled so I thought it wasn't going to work.

All I did was point EIP to a JMP ECX in nSEH and SEH just to be sure but it wasn't working.

After thinking hope was lost I realized in my case there was an irrecoverable exception and it wasn't calling my SEH handler because my buffer overflow was going completely out of the bounds of the modules stack!

I found out the exact current stack size and modified my overflow to use less bytes so it ends just before leaving the stack frame.

This was all I needed to do and my JMP ECX inside the SEH successfully pivoted into my buffer and allowed me to start executing the rop chain I was working on. Hope this helps I stayed up all night working on it.


Unable to execute shellcode in basic buffer overflow example

I see two problems, besides the null byte problem which I'm unable to reproduce (on an Ubuntu 18.04 virtual machine).

The add al,al instruction at the start should be xor eax,eax. The weird thing is that the bytes \x31\xc0 which are at the start of your shellcode actually is the xor eax,eax instruction. If the \x31 is getting replaced with \x00 somehow, like you mentioned is happening elsewhere, that would turn it into an add instruction.
You're not setting the third argument for the execve system call. This can be done by setting the edx register to esp right after pushing 0x00000000 onto the stack.

xor    eax, eax
push   eax
push   0x68732f2f
push   0x6e69622f
mov    ebx,esp
push   eax
mov    edx,esp     ;set  the envp argument
push   ebx
mov    ecx,esp
mov    al,0xb
int    0x80

As for the null byte problem, that is very strange because it sounds like there are null bytes in the actual buffer after it is written to by strcpy, which should not be happening. I would set a breakpoint immediately after the call to strcpy in assembly and inspect the buffer memory. Maybe you've already done this but use the debugger and make sure that the null bytes aren't creeping in somehow after the copying takes place.


Can you use https only for cookies and not the html?

No.  A response (and the associated request) is a single entity composed of headers (one of which is the cookies) and the body (in the case of the response, often HTML.  They are not separate.

Since the answer to question 1 is no, the answers to questions 2, 3, and 4 are also necessarily no, since this is not possible to do.


Is cell phone number based verification secure?

If it is not secure, are there any better alternatives?

It's secure for certain threat models, and the best tradeoff for accessibility vs attack surface. To intercept an SMS, you have to have some control over the routing of the messages or the device receiving it.
Without privileged information / insight provided at the carrier level, SMS is the best authentication method available despite its flaws including convincing users to send a 3rd party the code when they receive it.
If you need a stronger confirmation of some kind of connection between identity and a user online, you probably require something that's not a phone to be involved. Mailing a hardware token that is paired with a code displayed to the user is more secure, but it's also more costly and slower. Fido2 stands to prevent replay, but doesn't permit a sense of scarcity that phone numbers do as most people won't pay the money to be able to register lots of phone numbers unless you're getting into attestation signatures and that opens a whole new can of worms...
Each of these "stronger" solutions address different problems and raise additional cost and complexity burdens put upon either the company, the end user, or both. SMS remains the most attainable target for the general public.


How to authenticate securely while in public

lastpass + fingerprint identification.

Edit
I was being snarky. But technically everything is going to violate your rules. There will ALWAYS be another avenue of attack. In this case, they could steal your hand,  or lift your fingerprints as well as steal your laptop.

Edit Edit
Even going underneath a blanket is absurd. Acoustically they can determine your password by the sound of your keystrokes.


Feasibility of cracking a SHA256 of a UUIDv4

Assuming the UUIDv4 is generated with a CSPRNG (this is not guaranteed), it will have 122 bits of entropy. This is only 64 times easier than brute-forcing a 128 bit key, so it's still plenty far into the realm of impossible in our lifetime, even for a nation state (barring quantum computers fast enough to perform on the order of 261 hash operations with Grover's algorithm).


What happens if an attacker steals my sim card number?

The really secret stuff is stored inside of the SIM card in the form of an authentication key. The ICCID is not really very secret at all, it just uniquely identifies the SIM card but provides no way to perform the authentication process without the authentication key.


Which is more secure? AMD DASH or Intel vPro

DASH being open standard assures 2 things:

bugs can be found and fixed pretty fast, with the involvement of the community
there are no hidden backdoors

vPro has 2 problems:

is closed source and you cannot check for manufacturer back-doors
it was already hacked several times

So my vote goes to DASH hands down.


How can I add my website to preload entries set of well-known browsers like Firefox or Chrome?

All major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) use a HSTS preload list of Chromium.

You can check the eligibility and register the website to be included in the HSTS preload list on the https://hstspreload.appspot.com page.

As of today, the requirements are:

  Have a valid certificate.
  Redirect from HTTP to HTTPS on the same host.
  Serve all subdomains over HTTPS.

  In particular, you must support HTTPS for the www subdomain if a DNS record for that subdomain exists.

  Serve an HSTS header on the base domain for HTTPS requests:

  The max-age must be at least eighteen weeks (10886400 seconds).
  The includeSubDomains directive must be specified.
  The preload directive must be specified.
  If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to).


DMZ layer for web server/presentation layer

ASM, and other WAFs, are excellent.  They are not exactly a "tier", though.  The point of breaking things into separate security zones per-tier is defense in depth.  What happens if there is a remotely exploitable buffer overflow vulnerability in the service used for the presentation layer?  (*I know.  Impossible!  http://thehackernews.com/2013/11/Vulnerability-JBoss-Application-Servers-exploit-code.html)  You need 100% trust that the WAF will block it, despite whatever obfuscation technique thrown at it.  That is a lot of trust.  If the WAF fails to catch the issue, you are toast.  The hacker owns EVERYTHING.  They are inside the network and able to do whatever they want.

By layering you can limit damage and increase the chance of detecting a penetration.  Firewall -> WAF -> Presentation/Logic -> Firewall -> Data, at a minimum.

That's not all, of course.  You still need things like stored procedures and a heavily restricted user for access from Logic to Data layers.  The WAF might miss a clever SQL injection.  Maybe that data layer should also be in a DMZ of its own.

Keep in mind this is all logical separation.  One firewall cluster, one F5 cluster, one hypervisor cluster, and one pair of VLANed switches would support any one of your proposed layouts without blowing hardware costs out of proportion.  I am betting they are thinking adding security zones means lots of added hardware and complexity.  It doesn't have to.


Implication of URL injection in an URL shortener service

This is an inefficient way of doing things.The only security you would get from an external URL shortening service is that they will only shorten valid URLS, and not javascript code etc. However, you are still relying on their security that they will indeed shorten the URL provided by the user, they will be up 100% of the time, and have 0 security vulnerabilities. Why not write your own little parser that verifies URL's.
Somethings like this: https://stackoverflow.com/questions/205923/best-way-to-handle-security-and-avoid-xss-with-user-entered-urls

Some things you can look for:

1-The users have indeed entered a url starting with http:// and not some random java script code.

2- you can also use google safe browsing api to check the URL for malware. https://developers.google.com/safe-browsing/, this is very helpful as the google safebrowsing API will return malware for malware and 200 for valid URLS, for anything else such as invalid URL's the google api will return nothing.


What exactly is CVE-2016-3862 and how does it work?

I can't find any indication of this being active in the wild.

What is happening is that the code that examines and makes sense of image metadata, specifically the EXIF data is faulty. By carefully including invalid data (the details are not, of course, available), it is very likely causing a buffer overflow so that some of the data ends up in a memory space that belongs to active code and therefore gets executed. Clearly that memory space normally belongs to some privileged code. This type of issue accounts I think (last time I heard) for around 90% of all security issues in C/C++ code.

The problem with Android is that system updates are left to the carriers who choose when/if to send out updates from the phone suppliers who choose when/if to even apply fixes. It is a total shambles. It leaves many Android users with vulnerable phones. So while Google may have issued a fix, there is absolutely no guarantee that it will make its way through to handsets in use.


Has a HTTP server access to SSL session ID?

Whether the SSL session identifier is made accessible, by your SSL hardware, to the rest of the server, is entirely up to the interface that this hardware offers.

A decent SSL hardware box should offer some kind of session management, so that the consumer (your Apache / nginx / whatever server behind the box) may know whether successive connections are from the same client (i.e. the client reconnected, offered to do an "abbreviated handshake", and the box accepted because it still remembers the SSL session parameters). How this session management is offered is up to the box; it may or may not use the same "session identifiers" as what is exchanged in the SSL handshake (in the ClientHello and ServerHello messages). You will have to use to documentation for that box.

If the hardware does not offer session management of any kind, then it is junk and you should switch vendors.


Its not possible to "skim" a chip'n'pin card in the regular sense, as the card does have a encryption key (EMV), that is used to calculate a response to a challenge sent from terminal, which will both be verifyed by the bank. The key is known only by the bank and by the card.

The name "shimmers" came from a portmanteu of the word "shim" and "skimmers", shim refers to something thin, think padlock shims that are used to open spring-loaded padlocks. The "skimmer cards" are so thin so they fit between the actual payment card and the reader.
Such "smart card" shims are used also to illegally tamper with operator-locked mobile phones so they can be used with any operator. (basically, the shim will reside between the operator SIM and the phone, and "lying" to the phone that a SIM from the right operator is inserted)

However, there is 2 cases where a chip card can be misused, despite the security features:

1: Its possible to skim the details of the cards, EXCLUSIVE the CVV, as these are stored in clear-text on the card (its mainly required to store these details in clear-text as the bank must know which encryption key to use to verify the result of the transaction). This card number and expiry date can be used at any web shop where CVV is not required.

However, such a transaction would be easy to dispute, as according to standards, a initial transaction MUST have a CVV unless its a recurring transaction (CVV may not be stored anywhere). A bank can easily verify if you had any initial CVV enabled transaction with that merchant. (even if the initial authorizing transaction is later cancelled because the merchant don't want to charge right now, it still counts as a initial transaction)

Also, the merchant also very often takes the hit if VbV/3Ds is not used.

2: If a merchant does not have a valid online connection, the extra high security of the chip cannot be used. Instead a "offline transaction" will be used, where the card reader assert it has verified the PIN (or performed a signature transaction) correctly against the smart card, and supply a static signature/authorization code to the bank. Since the card reader has no means to verify a genuine card was used, it either has to deny all cards (so no goods are given to someone with a fraudulent card), or the bank has to accept all cards, including fraudulent ones (so a genuine card holder cannot use a fraudulent copy of his own card to gain goods and then claim he don't know anything of it).

This means, its possible to clone a chip card and use it in a offline terminal, along with the right PIN, or by signature.

The main defense to this is to require online verification of cards. Normally, a terminal is set to only allow a certain number of offline transactions before forcefully going into online mode (eg, refusing to process offline transactions). This number is then set by the aquirer, depending on the agreement with the merchant. In some cases, the terminal can request phone authorization, where the card will be validated "online" via a phone call made by the merchant.
A issuer can also require online verification by setting certain flags and bits in the static data portion of the card, then a terminal that lacks a connection will refuse to process the transaction. (This can be set specific on transaction amount, and differently if PIN, signature or no cardholder verification is used)

Note that a "online only" card can STILL be used for offline processing if a terminal is incorrectly set up, eg not following the EMV standard. A bank that conforms to the EMV standard should then refuse to process such transactions, as the merchant was told at processing time that the bank will not accept offline transactions.

The article that was linked, refers to this second method. With "not verifying the dynamic CVV value", it means basically that the bank allows transactions to be processed offline, either by allowing offline transactions based on the flags, or processing offline transactions even tough the card's flags tells that it may only be used online.

Note that for offline transactions, CVV is never verified, not even magstripe CVV for a mag transaction. The reason is for the same reason I outlined above - if the cardholder modifies the CVV value on the card or produces a counterfeit copy of his card, the cardholder could then purchase goods and then claim the transaction was made with a counterfeit card, and then not having to pay for the goods.

Thats why an transaction with an invalid CVV or cryptogram response, that was made offline, MUST go trough if the card's flags indicate offline transactions is permitted, regardless of the validness of the response.
(The invalid CVV or cryptogram response can however be used to automatically block* the card for future transactions)

*And same here: A bank MUST process a transaction made offline, on a offline permitting card, even if the card is barred (eg, you called into the bank's hotline and told them you lost your card) until a specific time passes. Theres a set limit of time that must pass before the card is definitely barred, this time is the interval the merchant has to update its blacklist. This is why transactions may appear on your account despite you have called and told them you have lost the card. The list of lost cards must be distributed to every offline terminal, and those might only be recharge its list of lost cards each 6/12/24 hours.


How to protect your anti virus program or logging agent?

If the attacker is logging from a bot or an automated remote tool: Possibly - by discovering that node and having an ISP trace the connections on it (White Hat) or by sniffing it and establishing a connection and locking out the controls. (Kind of difficult to do if it's on an active system being human monitored without locking out the attacker from their own system and even then they would pull the plug.)


If I visit a HTTPS website when using Tor, is my IP exposed?

No, it won't.

The thing is that when you use HTTPs over TOR you:

you use the public key of the server to encipher your message (so nobody except the server will be able to read your message).
then you pass the HTTPs message (which, remember, is encrypted with the public key of the server) to a TOR node,
this TOR node to another, and another and...
finally, the last TOR node will send your encrypted HTTPs message to the server (that includes your key for the session); the response is encrypted by the server with this key and you will be the only one to be able to decrypt the response from the server.1

So the graph should be as follow:

---> "Tor message"
===> "HTTPs message"
[T]  "Tor Node"
[S]  "Server"
[U]  "User"

[U]-->[T1]-->[T2]-->[T3]-->...[TN]==>[S]
[S]==>[TN]-->...[T3]-->[T2]-->[T1]-->[U]

And yet still your communication will be secret.

If you want to learn a bit more about how your connection is secret you can learn about the key exchange in this page.


Security-wise, is an in-browser JavaScript implementation fundamentally different from a server-side language (e.g. Python) implementation?

Are there attacks which are possible via untrusted code and data, but not via untrusted data only?

If you can trust the code you can usually use this trusted code to validate the untrusted data before further processing the data. If the code is untrusted too this is not possible. That's why the Javascript engine inside the browser (which is executing untrusted code) is running inside a limited environment (sandbox) so that the untrusted code cannot do harm to the underlying system. This means for example that file and network access is severely limited.

There are cases where the attacker manages to inject its own code into trusted execution environments. If this is the case the attackers code has the same level of trust then the other trusted code and can thus cause massive damage given that the assumption for the environment was that the code can be trusted. A typical example of such injection is to call eval on attacker provided data, thus interpreting these data as trusted code.

  In other words, is it a simpler task to secure a language implementation against malicious data only, compared to both malicious data and malicious code?

Yes, if the code can be fully trusted no additional restrictions need to be done to the execution environment since it can be expected that the trusted code properly validates the untrusted data. Of course restrictions are recommended nevertheless as part of defense in depth since most complex code has bugs.

If on the other hand the code cannot be trusted it is essential to limit what the execution environment can do. This makes it more complex since this protection is needed additionally to the existing language. And, all the bugs in the last years within the Java Sandbox show that designing and implementing such a restricted execution environment is not easy.


Storing Username in sessionStorage: bad idea?

Well done for thinking through the limitations of JWT. Most people don't and, as you've seen, most of the JWT tutorials on the web are horribly insecure.

One thing to note is that the delivery of a JWT to the server does not demonstrate that the originating device/browser is the one that was given the token in the first place. That is one reason JWT's should be very short lived because on their own, they are easily subject to token replay attacks. Even TLS does not guarantee freedom from a JWT replay attack - if the original PC was already compromised.

To add extra security, you need to be sure you need it. Obviously one of the reasons for using JWT is to lighten the load on the server. Adding server-side token validation and/or a session store clearly removes some of that advantage.

If you do need the extra security, you will either need to encrypt extra data into the token - e.g. ip address. Or you will need to store enough data in a session store to be able to sensibly validate that the token has come back from where you expected it to, again perhaps recording the originating IP address.

A session store is arguably more secure but probably not by much.

Your question regarding identity is easily resolved by storing the userid against the token in your session store if you are using one. If you decide you don't want additional security, then it is enough to store the id in the token as long as the token values are encrypted on the server.


Instead of:

alphanumeric password of reasonable length (36 possible characters over, let's say, a max length of 8 characters for a typical user) [does not account for special characters, but I already suspect there are other issues]
token

The system uses:

4 digit password (10 possible characters over a length of 4)
token

This is demonstrably a much weaker system, even if I design a very weak password system (outlined above). Plus, the UX is odd, but that's another factor.

But, is it too weak?

The fact that the token changes every 30s mitigates a lot of problems. Having a password means that if someone gets ahold of the token generator, the account still has some protections. But is 4 digits enough of a protection?

Two risks to consider:

Someone bruteforcing the pin+token pair

This is entirely up to how fast the system allows attempts within a 30s window. So, maybe it is secure enough. But do we really want to rely on a system throttle as a security measure? Throttles are a nice backup measure, not a primary mitigation.

Someone bruteforcing the pin if they have the token generator

Mathematically, to go through all the combinations would take 10,000 guesses (5000 on average to find success), if entered by hand, and if we assume perfectly random pins. That's a lot of ifs. Again, it is dependent on how many attempts the system will allow. Also, pins are notoriously easy to guess.

Compare this to a 'complex password' (however you want to define that) that you change frequently. Here's the thing: without the changing token, you change the time to bruteforce from 30s to 2 weeks (in your scenario). Now, the relevant factor is the complexity (or entropy) of your password and your system to reliably change it frequently. Again, a lot of dependencies.

As you can see, it is difficult to compare the factors that you laid out. A lot of 'ifs'. For the factors that I have control over and the risks that I am worried about, I might choose the pin+token (assuming that the 2FA is implemented properly (whoops, another 'if')).

But really, I'd choose another service that can implement 2FA properly.


Security risks from exposing ssh to a home server

Changing your port number is not considered a security counter measurement, we call this security by obscurity.
If one would scan your IP address they will find out an SSH daemon is running on an alternative TCP port regardless.
Based on your edited question it appears you are concerned anyone finding the SSH daemon TCP listening port. If this is the case, I would recommend to implement port knocking.
Port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of predefined ports. It could be configured in a way where you have to execute a script that will connect to X amount of ports.
If the right sequence is received by the port knock daemon, it will open up your SSH port in the firewall for X amount of time. A regular port scan will not be able to detect the SSH daemon at this point.
Hardening your SSH daemon is always recommended as the 'default out of the box' configuration is still using weak key exchange algorithms and ciphers.
By using strong key exchange algorithms and ciphers, most automated attempts will (currently) fail because the client (attacker) can not negotiate on either one of the algorithms or ciphers.
You could consider using my hardened configuration located at: https://github.com/ITNerdbox/hardening-configurations/blob/master/sshd_config
It might require some tweaking on your part in order to meet your requirement(s).


keylogger detection by listening network

A keylogger can send the data it gathers in a lot of ways:

Sent them by email
Encrypt them and send them by email
Upload a file to an FTP/SFTP server
Use HTTP Requests with GET/POST encrypted parameters
Use other protocols to send the data: special crafted DNS requests could be built, that hide the ex-filtrated data in legitimate DNS requests. It can also use reserved bits in packet headers to hide data there.
etc

As you can see, there are a lot of possibilities of sending data and the chances of a certain tool being able to detect all of these possibilities is rather low. This does not mean that using such a tool (like Snort) would not increase your overall level of security.

If you have a certain keylogger you are targeting (and you know how it works), then Snort rules could be created to accomplish your task.


Allowing a password reset if an account is locked

With the forgot password link your user can prove to have access to "something you have".
I would allow the reset of the account but would check more details like access to a second authentication factor (U2F, SMS, phone call, recovery codes).
You should also moderate this account. Only allow basic interaction and force additional authentication / admin approval / time delay / lock account when potential malicious behavior is detected after login (e.g. deleting settings, changing emails). So the real user would have time to react and there is also a message trail that something fishy is going on.
When the account would stay locked, an attacker could deny the real user to access the service by entering wrong passwords (denial of service).


Password managers with U2F security risks

I think the point of the saying "if attackers own your machine then you are already screwed" is showcased with your question.  You don't want your password manager to decrypt anything except the single password you're requesting.  But any malware on your system can intercept and change that request.  This theoretical malware can tell your password manager to provide it with all decrypted data while still giving you the impression that only one password was decrypted.

Once your machine is owned you shouldn't trust it to perform any function that can be compromised.  In reality this type of malware should be more difficult to create given its complexity, but you may not want to rely on that obstacle given your level of paranoia.

What you may prefer is a device separate from your computers or mobile devices to manage your passwords.  When you need a password you authenticate to the trusted device, read off that particular password, and enter it on the potentially compromised device.  Your password store is essentially air gapped, and you can focus more effort on preventing that device from being compromised.  That may not meet your other criteria of being simple.


Default GW IP address shared with management interface IP: any securirty implications?

Generally, the accepted best practice for management interfaces is to segregate them into their own VLAN and apply filtering so that only certain whitelisted (read jump boxes) are authorized to communicate with devices via the management interface.

The security concern is that many times management interfaces have:

Known vulnerabilities (e.g., HP SMH which seems to have a new one every week)
Weak or default passwords
Few controls to prevent bruteforce attacks (e.g., fail2ban, lockout windows, etc)
Devastating impact availability if compromised.


What does Windows's built-in encryption do, if I can seemingly always read my encrypted files?

Windows built-in encryption is done transparently at the filesystem level. The encryption key is stored in your account profile encrypted with your login password (this is why there's the warning when you change your password). So logging in unlocks the key, which then makes your encrypted files available.

Since the encryption and decryption is done transparently by NTFS, you don't ever actually see the ciphertext. If NTFS doesn't have the decryption key, it simply won't let you read the file. You can get to the ciphertext by reading the partition data raw, but there's no real advantage to doing that. The file can only be decrypted using the key I mentioned, which you never actually see.

Windows lets you back up your encryption key, where you export the key encrypted with another chosen password. This is useful if you ever put the disk into a different computer or reinstall Windows. But not really useful otherwise.

Since the encryption is tied to the filesystem, it's not designed for sharing encrypted data. Instead, you're protecting the files where they sit against anyone else who gets their hands on your computer.

If you want to create an encrypted container for transferring files to someone else, I'd recommend a compression tool that supports strong encryption. 7-zip is a great choice.


What's the difference between the endorsement key and the attestation identity key within the TPM?

Unfortunately there is not a single source of truth about attestation. I'll try to make it as clear as possible and cite when necessary.
TL;DR: The Endorsement Key is used to prove that you are talking to a real TPM. However, it cannot be used for signing. The AK can be used for signing and is associated with the EK.
Endorsement Key
You can consider the Endorsement Key (EK) fixed per TPM. Actually, the EK is the primary key of the endorsement hierarchy. As such, it depends on the Endorsement Primary Seed (EPS) which is really fixed for the lifetime of the TPM and a so-called template which e.g. determines if the EK is a RSA or a ECC key.
              EPS (random, can never be changed)
               |
            +-----+
template  ->| KDF |
            +-----+
               |
               V
               EK

Assuming, you use the default template, the EK is unique and not changeable for the TPM. You cannot change it ever. This raises privacy concerns which I will cover later. Also note, that the EK private key will never be disclosed by the TPM.
Additionally, a TPM typically provides an Endorsement Certificate (chain) which is saved on the TPM storage (e.g. ECC EK certificate: NV index 0x01c0000a, see TCG EK Credential Profile). This EK certificate contains the EK public key and is signed by the manufacturer. With that certificate you can verify, that the EK public key is associated with a genuine hardware TPM produced by the manufacturer.
I mentioned earlier, that disclosing the EK public key would violate our privacy (since we can never change it). Therefore, the TPM will not allow us to use the EK for signing. That is the reason why we need an Attestation Key (AK), previously also called Attestation Identity Key (AIK).
Storage Root Key
The Storage Root Key (SRK) is easy. It is the primary key of the owner hierarchy, that is the "father of all (normal) keys". All keys used by the owner of the TPM for signing and encryption are usually associated with the owner hierarchy and thus children (or grandchildren etc.) of the SRK. In fact, being a child of the SRK means internally being encrypted (= wrapped) by the SRK.
Attestation Keys
Now comes the tricky part. The term Attestation Key (AK), previously Attestation Identity Key (AIK) is defined very loosely. Basically any (restricted) signing key can be an AK.
TPM Spec Part 1, 25.3.1

A restricted signing key is occasionally referred to in this specification as an Attesting or Attestation Key.

The purpose of AKs is to sign data (e.g. PCR values) to prove that they originate from a real TPM (without having been tampered with). Remember, we cannot use the EK for signing directly.
There are two types of AKs I know of.
AK with AK Certfificate
First, the AK specified in the TPM Spec Part 1, 9.5.3.1. Basically, there is a trusted third party called Attestation CA with an own root key and a root certificate. The Attestation CA does a) verify the if a TPM is genuine via its EK Certificate and b) issue AK certificates if a TPM is genuine.
Now, different AKs and their corresponding AK Certificates can be used for attestation for different services (e.g. Google, Facebook). The service providers use the Attestation CA root certificate to verify if the TPM is genuine.

An external entity called an "Attestation CA" attests to an asymmetric key pair [AK] in a TPM in order to vouch that a key is protected by an unidentified but genuine TPM and has particular properties. This attestation takes the form of a credential [AK Certificate] that vouches for information including the public key of the key  pair.

Usually, this type of AK is associated with the owner hierarchy and thus a child (or grandchild etc.) of the SRK.
I think this tutorial might be helpful.
AK associated with the Endorsement Hierarchy
There is second approach to AKs. As I explained, the EK cannot be used for signing directly. However, it can be used to wrap (= encrypt) other keys. Therefore, you can create a signing key (AK) associated with the endorsement hierarchy.
Again, the service provider needs a mechanism to prove that a TPM is associated with a good EK / EK Certificate. In this case, the AK used is encrypted (= wrapped) by the EK. Only if a TPM can load (= decrypt) the AK under its unique EK and use it to sign data, it is a genuine TPM. In this case, the TPM loses its anonymity since the service provider needs to know its EK.
This approach is briefly described in this talk at LCA 2020 by Matthew Garrett.


sendgrid delivered malware - what's the abuse reporting procedure

Try and contact the suspect/victim first

It's possible that the entity you got this email from is a victim instead of an offender. It's polite to contact them first and report the issue. If you can't contact them (or they don't reply nor care), you can escalate it to SendGrid, and after that possibly even to GoDaddy.

For authenticated domain SendGrid provides a Forwarding abuse feature:

  Forwarding abuse

  The email address specified in the Forward Spam mail setting may also
  be used to receive emails sent to abuse@ and postmaster@ role
  addresses if you have authenticated your domain.

  For example, if you create a valid authenticated domain with a custom
  return path of sub and a root domain example and have turned on
  Forward Spam, any emails sent to abuse@sub.example.com or
  postmaster@sub.example.com will be forwarded to the email address
  you entered in the Forward Spam mail setting.

If the company is following the RFC 2142, 4, they could also have an abuse@example.com and/or security@example.com address available.
...or possibly a more "modern" /.well-known/security.txt file in place.

The abuse email information was available on SendGrid's web site.

Go to https://sendgrid.com/
Click on Contact Us

  Report abuse

  SendGrid is an email provider, but we don’t send messages directly to
  end-users. Please report email abuse to us, and we will be in touch.

  Report spam

Click on Report spam.

  If you discover spam that was sent by a SendGrid customer, please
  report it to our team by sending it to abuse@sendgrid.com.

  Our agents will be able to process your spam sample more quickly if
  you provide us with the full email headers of the offending message.

The contact information on WHOIS is behind a privacy feature:

  Registrant Email: Select Contact Domain Holder link at
  https://www.godaddy.com/whois/results.aspx?domain=SENDGRID.COM

From there I can find another similar abuse email address, but won't paste it here for the same reason. It is their own i.e. not the one specified as Registrar Abuse Contact Email.


Safe to download router firmware over unencrypted HTTP?

Sure - it could be a signed image. If the router has a built-in public key, and the image was signed by the corresponding private key, it would be perfectly safe.

Unless someone had got the private key, and uploaded a malicious version to the server, in which case, HTTPS wouldn't help either.


Why is MD5 considered a vulnerable algorithm?

I know that MD5 is the most vulnerable hashing algorithm

Well technically (we are technical around here) there are worse algorithms than MD5.

  and particularly vulnerable to Collisions

Yes, folks can create a desired hash with a different plaintext. This is not likely to happen randomly, but could occur maliciously.

  But the collision vulnerability is not very risky and somebody might use that as an advantage, but that's with sheer luck.

Not sheer luck. There are techniques to find a plaintext that produces a desired MD5. That's a good subject for a different question.

  OK, let's say I store passwords using MD5.

Ouch. The main reason you shouldn't use MD5 is because it is a General Purpose (Fast) Hash.

You should be using a (Slow) Password Hash such as

BCrypt is commonly recommended, but be sure to run a quick SHA-2 hash on the input data, so super-long passwords will not be truncated by BCrypt
PBKDF2 but that is less GPU-resistant because it has lower Memory requirements.
SCrypt is better than BCrypt if you have a high enough work factor. Otherwise it is worse against GPUs. (again, because of higher or lower Memory requirements)
The winner of the Password Hashing Competition may be even better than the aforementioned, but has not yet stood the test of time, so don't use it just yet. It's called Argon2, and has separate Work Factor settings for CPU time and Memory load. (nice!)
Repetitive SHA-2 can be used instead of PBKDF2 (still not GPU resistant), but this is more tricky to implement the repetition efficiently (i.e. to be brute-force resistant) because SHA-2 is actually a General Purpose (Fast) Hash.

Most of these options generate random Salt by default, but you should verify whether this is the case!

It is best to include some Pepper (~72 bits of entropy) before the Password prior to hashing. The Pepper can be the same for all your users, but should be stored in a file outside of the database so that component cannot be found via SQL Injection.

Make sure your Work Factor requires about 100ms (with appropriate DoS protection) on your target hardware (knowing that attackers will use faster hardware for Brute force)

Of course no amount of hashing will protect weak passwords, so include password strength requirements.

  collision vulnerability ... is there any way that the attacker can use this as an advantage?

In the context of password hash storage this probably will not help the attacker.


Are the bytes within a Sha256 cryptographically random relative to each other?

Well, if SHA-256 hashing exposed non-random patterns in the resulting byte sequence, that would indicate a remarkable design flaw. No such flaws are publicly known which is why truncating a SHA-256 hash is fine (as long as you consider that you end up with a shorter hash, of course).

That said, cryptographic hash functions are no random oracles and you should still be careful when using one as a PRNG.


Where can I find good dictionaries for dictionary attacks?

Nice list collected by Ron Bowes you can find here:
http://www.skullsecurity.org/wiki/index.php/Passwords.

Other list is from InsidePro:
https://web.archive.org/web/20120207113205/http://www.insidepro.com/eng/download.shtml.


How to access a shared webhosting webpage without the domainname?

It's completely normal that a site is only available with the domain, and it's vital for shared hosting: before the Host: header was added in HTTP 1.1 (RFC 2068, 14.23 from 1997, updated in RFC 7230, 5.4) every site required an own IP address, and before SNI (RFC 6066, 3) it was pretty much the same with HTTPS.

This same Host: header could be used in your situation, where Cloudflare's Web Application Firewall (WAF) is sitting between you and the target server, as you already have the original IP address that's supposed to be hidden behind the WAF. You have two options:

Add the Host: header manually with an intercepting HTTP proxy. You are probably already using one, as you are supposed to do some penetration testing.
Override the Cloudflare's IP address with the IP address of the destination server. The authoritative DNS servers are configured to give the IP address of the WAF, but you can locally override that e.g. by adding an entry to your hosts file.

Of course this should not be possible if the original server is properly protected i.e. only giving access through Cloudflare. For permitted penetration testing, your IP address should be added to the same whitelist. If this is not the case, please remember to add this in your vulnerability report.

Interesting reading close to the subject: CloudFlair: Bypassing Cloudflare using Internet-wide scan data.


How does the same-origin-policy protect against PUT/DELETE CSRF?

GET and POST are methods used in basic linking, embedding and in submitting forms. These kind of interactions between sites predate the development of the same origin policy. If the same origin policy would be extended to incorporate POST and GET too then lots of sites would probably break.

Therefore any POST and GET which can be created by linking, embedding or forms are excluded from the same origin policy. But GET and POST which use custom headers or similar which can only be created with XHR are not excluded because they never could happen in the old web predating same origin policy. See also Would the CORS specification consider a missing Content-Type header to imply a "simple header"? for more information.

  PUT and DELETE could be theoretically used for CSRF...However with the same-origin-policy these requests are not executed.

That's only true by default. If the target provides an appropriate CORS policy then PUT and DELETE could be used for CSRF too.


If a router has port 5060 open, and I know that there is unencrypted SIP traffic going through this port, how could one take advantage of this

port 5060 is normally assigned to SIP traffic. It might or might not be used for SIP however. A simple nmap scan to this destination should probably reveal much more, for example here's an output from a OS fingerprint nmap scan to a voip adapter

nmap -v -O <ip_address>
...
Host is up (0.0026s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:0E:08:CA:**:** (Cisco Linksys)
Device type: VoIP adapter
Running: Sipura embedded
OS details: Sipura SPA-1001 or SPA-3000 VoIP adapter
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: Incremental

Some implementations of SIP TLS appear to use port 5061 by default, but the reverse is not necessarily true. i.e. seeing port 5061 doesn't necessarily mean it's encrypted. I know of a few SIP installations where various ports are used for (standard) SIP, and they tend to range between 5060-5070... Again, those ports are completely arbitrary. You can choose to run a service on pretty much any port you'd like. So I can, e.g. run SIP TLS on port 80 and plain SIP on port 23 if I choose to... Until you do some kind of a probe / scan, you won't be able to know with a high-enough degree of certainty.

As far as VOIP / SIP security - there are probably many tools for scanning and potentially exploiting VOIP. A simple search revealed those items:

http://www.voipsa.org/Resources/tools.php
http://www.hackingvoip.com/sec_tools.html
http://blog.sipvicious.org/

and I'm sure you can find many others to experiment with.


What should you do if you catch encryption ransomware mid-operation?

Hibernate the computer

If the ransomware is encrypting the files, the key it is using for encryption is somewhere in memory. It would be preferable to get a memory dump, but you are unlikely to have the appropriate hardware for that readily available. Dumping just the right process should also work, but finding out which one may not be trivial (eg. the malicious code may be running inside explorer.exe), and we need to dump it now.

Hibernating the computer is a cheap way to get a memory image¹ Then it could be mounted read-only on a clean computer for

a) Assessment of the damage inflicted by the ransomware

b) Recovery of unencrypted files²

c) Forensic extraction of the in-memory key from the malicious process, other advanced recovery of the files, etc.

Note that by read-only I mean that no write is performed at all, for maximum recovery chances. Connecting normally to another Windows system won't provide that.

For (c) you would probably need professional support. It may be provided free of charge by your antivirus vendor.

Even if you don't manage to recover all your files or you are told it is impossible or too expensive, keep the disk with the encrypted files. What it's impossible today may be cheaper or even trivial in a few months.

I recommend that you simply perform the new install on a different disk (you were going to reinstall anyway, the computer was infected, remember?), and keep the infected one -properly labelled- in a drawer.

--

As for the second question, where you really want to pay the ransom I'm quite sure the ransomware author could give you back your files even if not all of them were encrypted. But if really needed, you could boot from the hibernated disk after cloning it, and let it finish encrypting your (now backed-up) files…

¹ NB: if you didn't have an hibernation file, this may overwrite plaintext versions of now-encrypted files that could have been recovered (not relevant for most recent ransomware, though).

² Assuming they are not infected…


Signing using a certificate and then the CA is out of business, how to prepare?

Is the chain of the old, saved public certificates along the data trusted anymore?

Yes, unless some reason for that trust to be revoked has taken place like a revocation or expiration.

  If it is, how come, if the chain to CA is broken?

The chain has not been "broken."  As long as all the public keys remain available, the chain is intact, regardless of any company going out of business.