Obviously allowing users to upload any file types is very dangerous

Anything a user uploads is just 0s and 1s until you actually decide to do something with it. Executing such files would be a bad idea, yes.

Executable programs don't automatically run unless you tell them to, though. If you are wondering about the autorun behavior of certain storage media this is now restricted to only cds and dvds in modern versions of Windows and has nothing to do with your web app.

If you have a clear set of file types you are expecting, i.e. only images then it would be easy to build a whitelist of expected file signatures.

Building a blacklist of "bad" files is a complete waste of time in my opinion.

Excluding .exe files or changing their extension would prevent users from downloading files and shooting themselves in the foot but with a bit of social engineering malicious files can be hidden and used in very creative ways. See 4chan.js which was uploaded as a valid gif file for an example.

For that reason I wouldn't bother taking it much further than banning .exe extensions. This is not something that would be a problem for your web app directly and you're only responsible for protecting users up a point. You can't be expected to bubble wrap them from across the internet.


In my opinion it is a bad way to have escaped data in the database. Since the escaping rules vary depending on the input an output medium (HTML, JSON, ...) they belong at the place where you input and output data and not in the database.

I recommend to use a multitier architecture where the data tier (i.e. the database) contains the plain (unescaped) data, the logic tier (i.e. business logic) works on these plain data and only the presentation tier (i.e. website, REST API,...) cares about escaping and unescaping data. This way the data will be properly unescaped (input) and escaped (output) depending on the escaping rules of the various input and output mediums (HTML, JSON, PDF, YAML, whatever...).

  ... but some other application may not have such mechanism to protect the users which the data is displayed to.

I your fear such kind of broken applications then you should also fear applications that use pre-escaped data with HTML escaping for outputting JSON or  which escape data again even they are already escaped in the database etc. You must have clear rules how the data are stored in the database (which not only includes escaping but also character encodings like UTF-8) and applications must know and follow these rules.


[...] how can an ISP manage to inject ads into a user's web traffic while using a VPN?

They can't. A proper VPN tunnel provides end-to-end encryption between you and the VPN provider.

Your ISP has no way of injecting any content into that tunnel. Your request to a plain HTTP site is only unprotected on the way between the VPN provider and the target site.

I find the advice from the article overall dubious. Here is another bit:

  If you really want to keep your browsing habits away from the prying eyes of corporations and the government, Tor is the best bet.

While Tor will keep your own ISP from reading your traffic, the author  ignores (or isn't aware) that there are a lot of nosy Tor exit nodes that monitor traffic themselves. Using Tor for regular browsing will eventually be worse for your privacy than relying on a reputable VPN provider.


Does the following data stream look secure to you?

Although the log files you show are relatively obscure, one can see some fishy things in the first few lines:

Apparently, the server which was contacted under the name secure.newsfarm.ams2.highwinds-media.com responds by sending a certificate which is meant for *.sslusenet.com, which does not match the server name.
The UntrustedRoot part is suggestive of a certificate chain which begins with an untrusted root certificate -- i.e., a chain which proves nothing to the client.

So it is like bypassing a security warning on a HTTPS Web site. This is vulnerable to active attackers.


Is including the SessionID even necessary if you are using encrypted ViewState? How could a malicious user generate a valid encrypted ViewState?

A malicious user could generate a valid, encrypted ViewState by visiting the page in question themselves and extracting the value. If the Session ID is not part of the ViewState value then this value will be valid for all sessions.

This is also mentioned on the Microsoft page Securing View State:-

  Per-user View State Encoding

  If your Web site authenticates users, you can set the ViewStateUserKey property in the Page_Init event handler to associate the page's view state with a specific user. This helps prevent one-click attacks, in which a malicious user creates a valid, pre-filled Web page with view state from a previously created page. The attacker then lures a victim into clicking a link that sends the page to the server using the victim's identity.

  When the ViewStateUserKey property is set, the attacker's identity is used to create the hash of the view state of the original page. When the victim is lured into resending the page, the hash values will be different because the user keys are different. The page will fail verification and an exception will be thrown.

  You must the ViewStateUserKey property to a unique value for each user, such as the user name or identifier.


How reliable is rpm --verify when auditing package integrity and what alternatives are there?

In my experience, rpm --verify is accurate enough for a first pass. I have not tried to remove a file and see if rpm --verify catches it. It does identify files that have changed.
rpm --verify is only ONE of the tools I use. I also use an intrusion detection system (AIDE) to identify files that have been added, removed or modified.
If there are specific files that I want to ensure their integrity, I use Puppet to control them. In short, Puppet uses a checksum to verify the integrity of the file. If it does not match, it can either send an alert, or replace the file with a correct version.


Nope, no software exploits, just classic exploitation of dumb users.

The payload is distributed in a self-extracting RAR file. A self-extracting RAR file is really just an executable extractor with the .rar file appended to the file. Such a file is an executable file with the .exe extension, and has a feature to run arbitrary code after extraction.

The steps are more like this:

User downloads a .exe file
User runs the .exe file (Fail!)
The .exe file extracts itself to the users Google Chrome profile to hide in
The .exe file run some code to make the extracted malware run and run at boot

There's really nothing original about this.

This post is based on the information in the following article:

http://www.bleepingcomputer.com/news/security/ransom32-is-the-first-ransomware-written-in-javascript/


What are the risks of storing passwords in a GPG encrypted file?

Your biggest problem is system compromise. If you store your key encrypted under a strong passphrase, then this is equivalent to the risk with a password manager (in fact if this is any indication, a lot of password managers don't derive encryption keys from master passwords correctly, so you're probably better off with gpg which does). So if someone roots your system and then you unlock your key, they have all your passwords. This is the same with any password manager that runs on your system.

If you don't encrypt your gpg key though, anyone who gets access to your system, even when its off (e.g. steals it) can read your key, decrypt your file, and get your passwords. This is worse than a good password manger (e.g. LastPass, KeePass, or even the OSX keychain).

Your second biggest risk is that that shell command writes tmp files to your system even if it deletes them (since deleting a file does not overwrite the data and it can be recovered with software). GPG might write temp files, grep might write temp files, less might write them. As might your shell. Moreover, since the last three of these are not meant to be secure, there is no reason why they might not decide to do that at some point in the future. On the other hand, a decent password manager would take steps to make sure it never wrote your clear text to disk. It could even only store your data in locked pages that don't get swapped to disk.

On the purely cryptographic side your max key size in gpg is probably 2048 bits. This gives you max 112 bits of security. To get something equivalent to AES256,  you'd need a 15360 bit key. This is the least of your concerns, but it still is one. Password managers usually use symmetric crypto so they can use AES128 or AES256.


Smartphone fingerprint plus iris scanning for login

Mobile phones doesn't use retina scanning.  The retina is the back of the eyeball (something only an optometrist would see if your eye was dilated), or you used a very specialized scanner.

Some new phones support iris recognition, which is the pattern of the surface of your eye made up on unique features such as blood vessels.  This would prevent the issue you're concerned about (access while not awake).

I'm not aware of any phones that support requiring multiple methods of authentication to unlock the phone.  Many phones offer the ability to unlock the phone via a biometric feature (face, finger, etc.) in addition to a PIN (in case the biometric fails).


Relative importance of CHROOT for web servers

I disagree with the idea that chroot is difficult - it just isn't appropriate for everything. For a small environment, with a server hosting more than one web environment, chroot is exceedingly powerful and provides controls around separation, and escalation prevention. Managing it is not a huge resource problem.

If you have an enterprise scale environment you may be less likely to use chroot (as it does become unwieldy in a large environment), but you are likely to have alternative controls which may include in depth monitoring, IDS/IPS , layered firewalls and SIEM.

I would class mod_security as an essential (for the webservers that have it or equivalent functionality) - it is an extra layer of defence which is simple to implement, and for most use cases it doesn't cause significant impact.

chroot and mod_security - as well as firewalls etc are all just layers of security which may help to prevent an attack or at least slow it, thus raising the likelihood you will spot it before it causes too much damage (assuming you are also monitoring...another control)


It is a bittorrent sync key.

  The mysterious string of characters published on the original The
  Piratebay domain is a BitTorrent Sync key. With the key it’s possible
  to gain access to a shared folder containing The Piratebay torrent
  database.

  Yesterday  the original The Piratebay domain thepiratebay.se came
  alive again. Besides a pirate flag image, hosted by the Isohunt, the
  site showed the amount of time elapsed since the Swedish police raided
  the datacenter in Sweden where the Piratebay was (partly) hosted. The
  site also showed an AES key which according to the Isohunt Twitter
  account is a BitTorrent Sync key, which allows to share folders.

  The folder shared with the key contains all .torrent files of The
  Piratebay, and a readme file with the text:

    -Place your stuff in the right categories
    –Keep the 6 categories that TPB had- Audio, Video, Applications, Games, Porn and Other
    –
    IRC: http://webchat.freenode.net – #tpbbtsync

    If they cut off one head, two more shall take it’s place…

    Hail HYDRA!

  The latter refers to a Greek mythological figure we reported about
  earlier today. The fact that the The Piratebay database is now
  distributed over Bittorrent Sync might indicate the site will never
  come back in it’s original form.


SSL/TLS client authentication - practical client cert validation

When the server uses IIS, client authentication means mapping the client certificate to an identity, i.e. an account (local account or domain account, depending on context). IIS may apply two distinct methods, with confusing names:

clientCertificateMappingAuthentication: IIS will look for a domain account that either contains a copy of the exact client certificate, or at least a domain account whose User-Principal-Name attribute matches the one contained in the certificate (as a Subject Alt Name of type otherName, identified with a Microsoft-specified OID). Use of the UPN is subject to some arcane conditions, including storing a copy of the immediately issuing CA certificate (not the root CA) in the "enterprise NTAuth" certificate store of the IIS server machine, or that of the AD server, or maybe both. You may use this blog page for some guidance.
iisClientCertificateMappingAuthentication: this one has two sub-methods, that IIS documentation calls "one-to-one mapping" and "many-to-one mapping". In one-to-one mapping, the IIS configuration contains explicit mappings from an exact certificate (the complete certificate in Base64) to an account (local or domain). In many-to-one mapping, the configuration contains some rules that basically match parts of the IssuerDN and SubjectDN, and explicitly map matching certificates to a given account.

In the non-Microsoft world, in the Apache Web server, you would use SSLRequire to implement access rules, based on elements extracted from the certificate (in practice, IssuerDN and SubjectDN).

What must be remembered is that:

Certificates are for authentication, not for authorization. The former is about making sure of who is calling, the latter about deciding whether that specific client should be allowed to perform the requested access. The IIS model does authorization primarily with access rights: once the certificate was mapped to an account, the rest is AD-specific stuff with no relation anymore with certificates; this could be simple file access rights, or possibly finer-grained authorization configuration with AzMan or whatever replaces it in recent Windows versions.

Trying to do authorization with certificates (e.g. issuing client certificates that contain some information such as "can do operation X") usually ends in tears and grinding of teeth. For all its clunkiness, the Microsoft method has the merit of clearly separating authentication and authorization.
There is always a certificate validation step, which ensures that the certificate is genuine and acceptable. This includes checking all dates, cryptographic signatures, name chaining, revocation status...
There may be an additional filtering on paths, like what IIS does when using UPN-based client certificate mapping: the presence of the issuing CA in the enterprise NTAuth store acts as an extra check that will reject certificate paths that are valid, come from an accepted root, but did not go through the expected intermediate CA.


Can't log in dvwa with a simple python program, even though login credentials are good

In order to login you need to also submit a hidden field called user_token which looks like this:

<input type='hidden' name='user_token' value='random_value_here' />

The value changes every time you refresh the page, so you need a little web-scraping to do what you are looking for. The following code uses bs4 to scrape the page and get the correct user_token value and then logs in successfully to the application:

import requests
from bs4 import BeautifulSoup

url = "http://127.0.0.1/dvwa/login.php"

def get_token(source):
    soup = BeautifulSoup(source, "html.parser")
    return soup.find('input', { "type" : "hidden" })['value']

with requests.Session() as s:
    src = s.get(url).text
    creds = {
        "username"   : "admin",
        "password"   : "password",
        "Login"      : "Submit",
        "user_token" : get_token(src)
    }
    r = s.post(url, data = creds)
    print r.text


ISO/IEC 27002:2015 Section 9) Access Controls
Subsection 9.4.2 - Secure logon procedures

"Implementing and using suitable authentication techniques, not disclosing sensitive information at log-on time, data entry validation, protection against brute-force attacks, logging, not transmitting passwords in clear over the network, session inactivity timeouts, and access time restrictions."


Security of shared "super pin" code table at meineschufa.de

We are talking about the database of a bank, and that's not your average database. It's a special kind of database, when every step is audited, every alteration is logged. So a database leak is very, very unlikely.

If someone can get access to the bank database, why bother with PIN or password for any user? They can go direct to the money.

The reason to send snail mail for the user is that the bank can almost surely know that only the real owner of the account have the reset codes. If anyone else tries to reset the PIN by using discovered information, it will fail because the fraudster don't have the reset codes.

And unless the fraudster can convince the owner of the account to disclose the codes, only the owner can reset the PIN.


Can I safely re-use an old, possibly compromised, hard drive?

It's unlikely that the hard drive itself was ever compromised, just the OS installed on the hard drive, which means it should be fine to format it and re-use it.

Simply doing a single pass with dd should be enough, no need to remove existing partitions as dd would overwrite the partition table anyway. Really, I don't see how there'd be much danger in just creating a new partition table without even wiping the data.

Note that it is possible for a hard drive's firmware to be compromised (a quick google will turn up plenty of stuff about the NSA), but as far as I know, if you're using full disk encryption (eg LUKS) the unencrypted data will never be sent to the drive, so data theft shouldn't be a big concern there (although that assumes you encrypt /boot as well, if malicious firmware can modify your kernel you're hosed).


If MP3's are being run from a network location, then these types of TCP window errors can be common. The MP3 player is trying to 'stream' the data, but is using a protocol that is not designed for efficient streaming.

These are not harmful, although other recommendations might be made about serving MP3 files over a network.


Can I use a mobile passcode login exclusively?

The rotating 6-digit code that is generated by the app on your phone does not run out. The number is based on a formula that uses a secret number (specific to the one account and known only to your app and the service that validates the code) and the time. So, as long as time keeps ticking, new codes will be generated.

I use old phones as 2FA code generators. They happily keep creating new codes every 30 seconds for years.

There is one weakness of the time-based system: if the clock on your phone gets out of sync with the clock on the service you are trying to log into. If your phone has no access to the cell network for a long time, there is a chance that the clock will slowly get out of sync. Then, eventually, the code that is generated won't match what the service expects.

So, steps to take? Make sure your phone can connect to the cell network every couple of months or so (or 6 or yearly). Phone clocks don't drift as badly as the clock on your microwave, but they will eventually drift.


what are the best counter measures against reverse engineering of firmware?

How can I best prevent, that critical commandos (e.g. open garage door) from an IoT device are being reverse engineered from the firmware? Is the following list complete / do you spot any errors? Any comments?

Don't try to prevent it. Accept that an attacker understands your protocol, but ensure that the protocol is safe, even when the attacker knows the protocol. This is known as Kerchoff's principle.
Even if your app and firmware is perfect, and impossible to reverse engineer, the attacker can listen to the communication in some way. If it's RF, a cheap SDR will let an attacker listen. If it's TCP/IP it's even simpler.
Focus on securing secrets, not code or protocols.
Mistakes like this is exactly what makes bad IoT security; the same key is used everywhere, because the firmware is hard to read... One break, and poof, your security is gone. If you have a good protocol, publication of your source code will not matter to the security of your system. It may make your business more difficult by revealing trade secrets, but it should not affect security.


Certificates for autoscaling internal networks?

An internal CA is the usual approach. You can generate certificates for each server with a short renewal time and have the internal CA root installed on your internal client machines (e.g. via group policy). You then set up some certificate management infrastructure to help you generate and deploy certificates.

As an example, Kubernetes maintains a CA per cluster, which allows each component and workload to securely communicate during administration tasks. They utilise CFSSL for doing the heavy lifting, which is the same toolset that allows Cloudflare to automatically deploy and manage certificates at scale.


Do whatever results in less / simpler code.

From a threat model perspective, if an attacker can access one file, they can access the other. You're much more likely to run into issues with logical flaws in your code, so keep the code simple and short. Pick whichever of the two choices offers you more simplicity.

Also, make sure you understand password hashing properly, and follow good practices.


this approach is already found in various frameworks and works (more or less) against basic attack-patterns.

another, more elegant way is to use CSP, but you have some requirements when using this approach (no inline js/styles etc)

the problem is, from defender-pov, an attacker might have other points), nasty stuff like encoding, nullbytes and different ways to mitigate protection. if it were just ASCII, the world would be ( a little more) perfect :)


Should an admin user be able to edit passwords?

I see three related questions:

Should an admin user be able to view a user's password? No.  This is a bad idea.  You should not expose (through the admin interface) a way for admin users to view other users' passwords.  Some users may re-use passwords on multiple sites.  Therefore, users should never be allowed to see the user's password.

Also, the only way to allow an admin user to view other users' passwords is to store those passwords in the clear (or, if any transformation is applied, it has to be reversible, in which case the passwords might as well be stored in the clear).  This is bad security practice.  Stored passwords should always be hashed, so that a breach of your database does not trivially reveal everyone's passwords -- and that means admin users won't be able to view other users' passwords.

Should an admin user be able to reset a user's password? Sure.  That's useful.  For instance, it is reasonable to give the admin user a way to reset the user's password, e.g., triggering an email to the user to allow them to log on and enter a new password, or generating a new password for the user and emailing it to the user.  However, the system should not display the new password to the admin user.  Also, in this case the user should get some notification that the admin reset their password (e.g., as part of the email that is sent to them), and preferably the action should be logged along with the identity of the admin user.

Should an admin user be able to set a user's password? This is useful and reasonable functionality to provide to an admin user.  For instance, when creating new users, it is sometimes useful for an admin user to be able to generate a password for the user, enter it into the system, and communicate the password to the user over an out-of-band channel (e.g., over the phone).  Similarly, it can also sometimes be useful if there's a way for the admin user to go to the screen to set a new password for the user, give the user the keyboard long enough to type in their preferred new password, and then click "ok" and set the user's password.  These are reasonable use cases which you could reasonably support, without incurring significant security risks.  In this case, the user should receive some notification that the admin reset their password (e.g., an email that is sent to them), and preferably the action should be logged along with the identity of the admin user.


Can EAP-TLS and AES256 encryption be used together?

What is the difference between EAP-TLS and AES 256 encryption?

They are not just different protocols, they are entirely different concepts.

AES - the Advanced Encryption Standard - is a block cipher algorithm. In AES-256 the 256 denotes the key size (different key sizes also trigger slightly different of AES). AES can be used for the transport encryption used within TLS; i.e. it can be the cipher that actually encrypts the payload. AES is a subset of Rijndael standardized by NIST.

EAP describes a framework for authentication. The authentication mechanisms provided by EAP-TLS can be used within the handshake of TLS to authenticate the client and/or server. Usually it is used to perform both client and server authentication though (compared to web browsers that usually only perform server authentication).

So we aren't comparing apples and oranges here, we're comparing apples and asparagus.

  Can they be used together? Or are they separate protocols?

The handshake phase and the actual encryption/decryption phase of TLS are not directly coupled. So yes, if this combination has been implemented by the client and server, you should be able to use both.

However, the EAP-TLS specification only requires the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite to be available for the use of AES. And that's a SHOULD, not a MUST, so you need to check this as well at the client and the server (although this cipher suite is generally supported). If a ciphersuite with AES_256 is supported it is not a standardized solution.

AES-128 is considered very secure; AES-256 may not make that much a difference with regards to security of the entire system. Note that I don't see an option for forward secrecy (DHE or ECDHE cipher suites) or TLS 1.2 either. That should probably worry you more.


When (if ever) should web app force numerical, generated (hence hard to remember) logins?

In my opinion, never.

Like you said, a proper password policy already serves the purpose of lowering the likelihood of a bruteforce attack being successful.

Forcing randomly generated numbers on a user is a sure way to give yourself a headache, as the number of "Forgot Password" request will be overwhelming.

Worst case - it forces the user to write the number down somewhere easy to find.


Which is the best antidote for DNS cache poisoning?

But, which is the more effective?

They address slightly different issues:

Port randomization makes DNS spoofing harder because there is an additional unknown secret for the attacker (the port) which must match for the spoofed answer.
With DNSSec one can reliably detect if the answer was spoofed.

  Which solutions are really deployed in the nameservers today?

DNSSec everywhere could probably make port randomization obsolete, but currently we are far from a sufficient adoption. For the mean time we need port randomization. But this is not a server side solution, but instead must be done by the client (a DNS cache works as a client when asking another DNS server).


Realistically, you cannot stop a bad guy from sending deauthentication packets.

Instead, you should focus on ensuring you are resilient to a deauth attack.  Make sure your network is configured in a way that the deauth attack doesn't enable an attacker to compromise your network.

To do that, you need to make sure you are using WPA2.  If you are using a pre-shared key (a passphrase), make sure the passphrase is very long and strong.  If it is not already, change it immediately!  If you are not using WPA2, fix that immediately!

The primary reason why bad guys send deauth packets is that this helps them execute a dictionary attack against your passphrase.  If a bad guy captures a copy of the initial handshake, they can try out various guesses at your passphrase and test whether they are correct.  Sending a deauth packet forces the targeted device to disconnect and reconnect, allowing an eavesdropper to capture a copy of the initial handshake.  Therefore, standard practice of many attackers who might try to attack your wireless network is to send deauth packets.  If you are seeing many deauth packets, that is a sign that someone may be trying to attack your wireless network and guess your passphrase.

Once the attacker has sent a deauth packet and intercepted the initial handshake, there are tools and online services that automate the task of trying to recover the passphrase, by guessing many possibilities.  (See, e.g., CloudCracker for a representative example.)

The defense against this kind of attack is to ensure your passphrase is so long and strong that it cannot possibly be guessed.  If it's not already long and strong, you need to change it right away, because someone is probably trying to guess it as we speak.

(The other reason a bad guy might send deauth packets is as an annoyance.  However, as most users probably won't even notice, it's not a very effective annoyance.)

To learn more, see these resources:

How does deauthing work in aireplay-ng?
Can someone get my WPA2 password with honeypots?


Why do some web servers still provide information on vendor and version in the HTTP response headers

Yes, in theory by advertising vendor and version in the banner makes an attacker's job easier, but like only a little bit.

Even if you don't advertise it, it can be figured out from the behaviour of the app. Take for example, the network scanning tool nmap:

  Nmap provides a number of features for probing computer networks, including host discovery and service and operating system detection. These features are extensible by scripts that provide more advanced service detection, vulnerability detection, and other features.

Source: wikipedia

  After TCP and/or UDP ports are discovered using one of the other scan methods, version detection interrogates those ports to determine more about what is actually running. The nmap-service-probes database contains probes for querying various services and match expressions to recognize and parse responses.

Source: nmap documentation.

Basically, nmap will start by trying to decide if it's apache / nginx / IIS, etc, which it will do by sending a specific packet to which it knows that the different web servers will respond differently. Then, once it knows that it's apache, it will send packets that target behaviours that have changed between one version and another, possibly because of a bug fix or because of a new feature.

As noted by @paj28 in comments, nmap is quite good at detecting the vendor, but hit-and-miss with version, when nmap displays detailed version info, that's probably because there was a banner. Of course, if you're trying to hack in, why bother trying to figure out version at all; once you know it's apache, why not just run all the apache exploit scripts from metasploit at it and see if any of them stick?

So yes, in theory it's possible to write a specification for "Here's how all web servers MUST behave", but that means that you're not allowing web servers to ever innovate, or fix bugs.  Moreover, web servers will want to differentiate themselves with features that other servers don't have.

As pointed out by @TripeHound, version banners can be considered a win for security as they allow sysadmins to easily inventory their systems and keep them up to date.

TL;DR: Banner or not, you can figure out what web server and OS you're talking to.

Nmap Example

Since this post got popular, I'll add and some examples:

Apache httpd puts version info right in an HTTP header:

HTTP/1.1 200 OK
Date: Thu, 17 Oct 2019 14:26:10 GMT
Server: Apache/2.4.6 (CentOS)

and unsurprisingly, nmap picks this up:

 ~ nmap 192.168.56.107 -p 80 -A --version-all

Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-17 07:58 EDT
Nmap scan report for 192.168.56.107
Host is up (0.0020s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.6 ((CentOS))
| http-methods:
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/2.4.6 (CentOS)
|_http-title: Apache HTTP Server Test Page powered by CentOS

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 14.23 seconds

If we try something a bit trickier, Apache Tomcat does not give an obvious banner:

HTTP/1.1 200
Accept-Ranges: bytes
ETag: W/"1896-1527518937672"
Last-Modified: Mon, 28 May 2018 14:48:57 GMT
Content-Type: text/html
Content-Length: 1896
Date: Thu, 17 Oct 2019 14:35:05 GMT
Connection: close

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Apache Tomcat</title>
</head>
...

we see that nmap gets the vendor right, but does not have a guess at the version:

~ nmap -A -p 8080 192.168.56.1

Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-17 10:34 EDT
Nmap scan report for 192.168.56.1
Host is up (0.0013s latency).

PORT     STATE SERVICE VERSION
8080/tcp open  http    Apache Tomcat
| http-methods:
|_  Potentially risky methods: PUT DELETE
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Apache Tomcat

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.71 seconds


What to do when my router is infected with a malware (becoming a part of a botnet)?

Google should tell you that your router model are vulnerable to Mirai botnet attack.

I don't think you can "buy" any OpenWRT router because it is about flashing an router that "flashable" with OpenWRT, there is chances to brick the router. So it is more towards DIY activities with no support from router vendor.


Make sure you're using WPA2 with a strong password.
Change the password.
Use a Wifi Analyzer to make sure you're on the least crowded channel you can be.
Disable WPS (Wi-Fi Protected Setup), pin can be brute forced.
Change default router configuration login

That's all you can really do, and all you need to do.

(I do not consider MAC address filtering sufficient to help with much of anything, so don't bother)


since Internet Explorer seems to be the only browser vulnerable to
  this attack.

That is the false assumption which is largely responsible of your situation because on February 2015, Microsoft already released  HTTP Strict Transport Security in Internet Explorer 11. It is clear, regarding the error message you got, that your IE version is 11 or higher.

  i.e a DOS of some sort

No, SSL stripping has nothing to do with DoS.

  exception.runtimeerror : request.write called on a request after
  request.finish was called

It is normal you got that error since you know the purpose of HSTS and which not not only makes your connection fails, but  can also, in case you attempt your MITM on other users, inform them (your potential victims) that they have been  tampered by a third party.

  And when it does work I get this error message :

Now you can guess you misinterpreted the events: since the error message by itself warns you that the connection failed.

Now, a question you may ask: is this the end of SSLstrip ? Luckily (or unluckily, depending on the colors you wear), there is an other opensource tool that uses an updated version of SSLstrip called mana. If you are running Ubuntu, Kali or any other Debian distro, you can install it by runnin:

  apt-get install mana-toolkit

So in addition to HSTS limitations, mana overcomes and tricks HSTS.


DNSSec requests are normal DNS requests with the DO (DNSSec OK) flag set. DNSSec responses are also normal DNS responses which also include records (RRSIG) related to DNSSec.

DoH and DoT both simply send the original binary DNS request and response inside a TLS connection (DoT) or as body or query string inside a HTTPS connection (DoH). DoH can additionally send the DNS messages as JSON  which essentially can do the same as the binary representation, only with more buzzwords triggered, more bandwidth needed and more overhead in processing.

There are no restrictions by DoT or DoH what kind of DNS messages can be sent. This means that DNSSec can also be done with DoT and DoH.


Why are hash functions one way? If I know the algorithm, why can't I calculate the input from it?

Let me invent a simple "password hashing algorithm" to show you how it works.  Unlike the other examples in this thread, this one is actually viable, if you can live with a few bizarre password restrictions.  Your password is two large prime numbers, x and y.  For example:

x = 48112959837082048697
y = 54673257461630679457

You can easily write a computer program to calculate xy in O(N^2) time, where N is the number of digits in x and y.  (Basically that means that it takes four times as long if the numbers are twice as long.  There are faster algorithms, but that's irrelevant.)  Store xy in the password database.

x*y = 2630492240413883318777134293253671517529

A child in fifth grade, given enough scratch paper, could figure out that answer.  But how do you reverse it?  There are many algorithms people have devised for factoring large numbers, but even the best algorithms are slow compared to how quickly you can multiply x by y.  And none of those algorithms could be performed by a fifth grader, unless the numbers were very small (e.g., x=3, y=5).

That is the key property: the computation is much simpler going forwards than backwards.  For many problems, you must invent a completely new algorithm to reverse a computation.

This has nothing to do with injective or bijective functions.  When you are cracking a password, it often doesn't matter if you get the same password or if you get a different password with the same hash.  The hash function is designed so it is hard to reverse it and get any answer at all, even a different password with the same hash.  In crypto-speak: a hash function vulnerable to a preimage attack is utterly worthless.  (The password hashing algorithm above is injective if you have a rule that x < y.)

What do cryptography experts do? Sometimes, they try to figure out new algorithms to reverse a hash function (pre-image).  They do exactly what you say: analyze the algorithm and try to reverse it.  Some algorithms have been reversed before, others have not.

Exercise for the reader: Suppose the password database contains the following entry:

3521851118865011044136429217528930691441965435121409905222808922963363310303627

What is the password?  (This one is actually not too difficult for a computer.)

Footnote: Due to the small number of passwords that people choose in practice, a good password hash is not merely difficult to compute backwards but also time-consuming to compute forwards, to slow down dictionary attacks.  As another layer of protection, randomized salt prevents the use of precomputed attack tables (such as "rainbow tables").

Footnote 2: How do we know that it is hard to reverse a hash function?  Unfortunately, we don't.  We just don't know any easy ways to reverse hash functions.  Making a hash function that is provably difficult to reverse is the holy grail of hash function design, and it has not been achieved yet (perhaps it will never happen).


Problems accessing websites in Netherlands

I believe those sites are detecting you have a VPN or proxy in place, and responding accordingly. It haven't anything do to with the country, but the site administrators.

  changing my mac address

This is irrelevant. You MAC address don't leave your local network anyway.

  I read an article here about setting up a vpn on a vps, but I dont think that will do any good

It can work or not, depending on the site administrators. If they detect your IP is from a range used by a VPS company, they can block you. You can rent a VPS on a small, cheap and unknown provider for a month and test. You can find hosting for a dollar a month, so it's worth testing.

You can try any VPN provider too, most of them have a free tier, or a trial period  when you can test the service and cancel without being billed. You can try those too. They are easier than to setup and maintain your own VPN, but are more expensive. On the other hand, maintaining a VPS can be very educative.


Someone is using similar domain and spamming clients

Use a tool like http://www.tcpiputils.com/ to find out who owns the fake domain and who hosts the fake domain and locate the "abuse" email. Send them samples of the fake emails. This should help to take the fake domain down.

Meanwhile, send warnings to all the clients that there is active criminal activity going on.

As for whether or not someone knows the communications between the company and the clients, there is not enough detail to provide any answer about what to do about that.


Decrypt AES 128 CTR with the IVs (counter) but not the key

No, there is no way.

The encrypted data and the IV are collectively called "the ciphertext", this is what is sent over the internet when you encrypt something. The details of the counter function (and the details of how AES works in general) are also public information. The only thing that's meant to be secret is the key, which you don't have.

In short, you have the cipher text but not the key. Unless you know of some secret military-level hack against AES, then you will not be able to recover the plaintext, ... that's the entire point of AES.


Can smart power meters read key presses on a wired keyboard?

It is extremely unlikely that a smart meter would be able to read the keystrokes off a keyboard, even with custom firmware. Doing that requires three things which a smart meter lacks:

An extremely accurate power monitor with a high sample rate.
Samples are typically taken every 30 minutes, but can be taken as fast as 6 times per second. This is not enough to monitor the rapid power use variations of a keyboard microcontroller.

A large and high-speed storage system to record raw samples for later processing.
According to at least one standard for smart meters, they must be able to store 13 months-worth of data consumption information at 30 minute sample intervals. This is not very much.

A powerful processor (or FPGA) capable of filtering out the noise.
A quick search for random technical specifications for a smart meter show one example running an ARM Cortex M4, with 256 KiB of system memory. This is not nearly sufficient.

Smart meters have several options for monitoring power: shunt resistors, Rogowski coils, Hall-effect sensors, and current transformers. As far as I am aware, none of these techniques have accuracy greater than +/- a few milliamps. Accuracy of Rogowski coils, for example, can be up to 0.5%, although manufacturing tolerances often result in it being as low as 5%. Monitoring an 8051 processor with a high-precision sensor connected directly to the microcontroller power source requires at least 12 bit sample size, with the sample rate being an integer multiplication of the clock source (millions of times per second at a minimum). Traditional power monitoring solutions cannot accomplish this.
There has been a paper from 2009 on this subject which focuses on both USB and PS/2 keyboards, and details a number of techniques to analyze the keystrokes. While the paper focuses on EMSEC (compromising electromagnetic emanations), the concepts involved should be fairly similar. A single recording had to be processed for two seconds by a powerful processor. A dedicated FPGA would be required to analyze the samples in real time, not a low-power ARM processor.
Now, there are privacy concerns with smart meters. At a high enough sampling rate, they can determine what channel is being viewed on a television, as the net power usage from the screen varies based on what is being displayed. I don't have a paper to link to, so this is just from memory. It may or may not apply to modern LCD displays where the power usage is roughly similar regardless of what is displayed. But are they able to perform efficient power analysis attacks against low-power microcontrollers in an entire home full of devices, using nothing more than a firmware update?
Virtually impossible.


what should be done to use sodium in a secure way?

General Advice

Know if you need to use libsodium at all! Usually, TLS for encryption in transit is enough, but it depends on your use-case. Make sure that you know what is required of your solution and which algorithms are designed to fill these use-cases. (A good example of what not to do is to encrypt something with AES-CBC and believe this means the data can't be modified.)

Secondly, stick to the recipe! With cryptography, it's easy to get things wrong, even if everything seems to work fine.

Finally, have your code audited by a professional auditor. The ability to do so naturally depends on the scope of your project. If it's a hobby project, then it's not necessary to do that, unless having heaps of money laying around is a problem you want to solve.

Securing your Keys

The problem you indicated in your question is that you are unsure how secure the key-material is. In an example, you stated that if an attacker has access to the script that performs the encryption, they could just steal the key and thus decrypt your data. This is correct, which is why you need to implement proper key management.

Doing that is easier said than done, and proper key management could fill books. The extremely simplified version is that keys need to be generated and then stored, until they are finally rolled over and then either archived or destroyed.

If your code is just $key = random_bytes(SODIUM_CRYPTO_SECRETBOX_KEYBYTES);, what you are doing is literally generating a new key on every call. This might be what you want, but it could also not be what you want. Perhaps you will use that key as a DEK and encrypt it with a public key, or you will send it to the user, or do any number of things with it. Perhaps you would rather derive that key from a password that the user has inputted. You have to know these things beforehand, and make sure you use the right cryptographic primitives.

Securing your Server

It's vitally important that you secure whichever platform you use to store your keys. If an attacker can gain access to the server that runs your crypto, then you can pack up and go home, because the game is over. It is absolutely vital to ensure that an attacker has no way of running their code on your servers, or has any other way to get even a hint at the key material you use.

If you, for instance, store your keys in a 32-byte wide database field, and an attacker can read out your database, then all keys have been leaked.

To Summarize

Crypto is hard, so the less of it that you need to do yourself, the better. Check if you actually need to write crypto-code yourself. If not, don't do it.

Read up on key management, and make sure you have strategies on what to do if things go wrong.

Secure your server, because if it's compromised, you have lost.


All client side code insecure by design. Unfortunately no matter how well you code your function, it can be easily bypassed by the end user. If this data is going to be passed to a server please validate it at the server end as well.

Client side validation is purely for 'usability' and not security (i.e. let the client know that they have added an incorrect answer, genuine users will change their answer to conform, malicious users will edit the code or use a proxy to send off malicious text). For security you must check it on the server side.


www-data is sending rogue mails through sendmail. How do I find the source?

From your update I'd guess that PHP fusion is the problem here.  It looks like there's wide range of vulnerabilites for newer versions than that including SQL Injection and other pretty high risk stuff  (sample info here), so it's reasonable to assume that the one you're using is vulnerable too...

So it would be likely that your attackers have got access to your server that way with at least the privileges of the web server user.

At this point really you need to look at rebuilding the server as it's very hard to effectively clean someone off your system without knowing exactly what they've done (e.g. put rootkits on the system)

If you have backups from before the problem started you could work from that, although it could be tricky to tell exactly when they got access.

Key point would be to ensure that you have fully updated versions of all the software you use and make sure to keep the CMS updated as they can be common points of attack.

Also looks like there's some advice on the php fusion pages (here) on recovering from this kind of attack


is there any way for me to be able to get the full hash?

No.

You didn't name your hash function. So I'm assuming, you're talking about a regular cryptographic hash function, like SHA-256 for example. In your regular cryptographic hash you want what is called the "Avalaunch Effect". It means that if even one bit of the input is flipped, added or removed, then the hashed output is very, very different.

For completeness sake: Two other non-cryptographic hashes:

Checksums
If you don't care about attackers, then you might want do use a faster hash, that isn't a cryptographic hash. This is sometimes also called a "checksum". Like CRC-32 for example.
There the emphasis is on detecting transmission errors and not malicious manipulation.
Similarity preserving hashes
If you actually want similarities to be preserved, then the last thing you want is the Avalanche Effect. For example if you have a large collection of files and want to sort them by similarity. Or if you have a virus sample and want to know if another file is somehow virus-y in that way as well. One hash that does this and preserves similarities is "ssdeep". VirusTotal.com uses it on its results pages.


Yeah basically you need a vulnerability to exploit in order to direct code execution to your shellcode or payload, which can be anything from popping calc to a meterpreter or command shell. This link is a great reference for metasploit in general and specifically about some of the points about payloads it sounds like you are interested in.

http://www.offensive-security.com/metasploit-unleashed/Payloads


What method for CSRF token generation should I use in my scenario?

For generating the CSRF Token I was thinking about generating a salted hash from the .ASPXAUTH cookie. Would this suffice in the protection against CSRF, assuming XSS is blocked and the authentication cookie isn't hijacked?

The answer is yes, it's sufficient, assuming you have marked the ASPXAUTH cookie as HttpOnly.

The token needs to be a hard-to-guess value that the server can correlate with the session cookie.  A hash of the cookie works quite well.  Since it is HttpOnly, scripts running on the browser will be unable to read it and won't be able to forge the hash.


are some IP whois capable of going beyond proxies?

whois on an IP address shows whom this IP address (range) is assigned to. If you get that the address is assigned to some company doing anonymous  proxies then this is exactly that, i.e. there is no way to look behind since there is nothing behind. What you would need to look further is the original IP of the user which an anonymous proxy hides by design. And behind the one IP address you see there will probably be many hidden IP addresses you don't see.


Your understanding of setuid is correct. When you execute a program that has the suid bit, the process inherits the permissions of that program's owner. The piece of knowledge that you're missing is what the shell does after it's been invoked. Many popular implementations of sh drop privileges when they start up: they reset their effective UID to their real UID. This includes bash, dash, mksh and BusyBox sh, so on Linux you won't see anything else.

When the program runs a shell (e.g. by calling the system function from the standard C library, or an equivalent in another language), the shell starts with elevated privileges but drops to ordinary privileges before it executes any user code. This mitigates exploits in setuid programs where the attacker only gets to run a shell command which wasn't intended to run with elevated privileges (e.g. because the shell command was buried in library code that the application programmer wasn't aware of).

This doesn't mitigate exploits where the attacker gets to run arbitrary code. It's just that to get a shell, you have to work a bit harder than calling system. Arrange to call some different interpreter, e.g. run execve("/usr/bin/perl", "/usr/bin/perl") (fork first if you don't want to terminate the parent program).


Which digest algorithm to use with creating a public/private key pair

digest_alg is not used by openssl_pkey_new() but by openssl_csr_new(): the latter creates a public/private key pair and wraps the public key into a certificate request, which is self-signed (with the newly generated private key). That signature involves using a hash function, hence the parameter.

openssl_pkey_new() entails no signature and thus has no need for a "hash function" parameter.

For openssl_csr_new(), your sensible choices are between SHA-256 (robust, recommended, efficient) and SHA-1 (theoretically less robust, no longer recommended, a bit faster, and, more importantly, supported everywhere). IE 8.0 on Windows XP (with all updates) supports SHA-256 for certificates (I have tried it yesterday), so I incline to assert that SHA-256 is now sufficiently well supported that it can be recommended "by default".


Presence of table "sqlmapoutput" in PostgreSQL database

This is the result of someone running sqlmap on the database. (Specifically here) Either this is

An honest pentester:

In this case, delete the table and fix whatever vulnerability they discovered.
Some other actor:

Consider all data comprimised. Search for whatever hole caused this and fix it, and if you have users force them all to reset their passwords.


Plain text Rails environment variables and security

What matters here is a question of threats and of defense lines. The threats I can imagine are:

a vulnerability in the web server allows an attacker to read files from the web application folders
a vulnerability in the web server allows an attacker to read the environment variables of the application
a vulnerability in the web server allows an attacker to execute arbitrary commands on behalf of the legitimate app
a vulnerability in the server (independantly of the web application) allows an attacker to gain access to the server

Then, you have 2 possible defense lines (ideally you should combine both)

reduce the exposition risk

ensure that the web application stack is consistenly patched
ensure that the web application is hidden behind a reverse proxy: this can help to ensure that only HTTP requests to acceptable URLs can reach the server - the URL rewriting of the proxy can map incoming URLs to a subpath to guarantee that no URL at root can be received
ensure the datacenter is correctly protected behind a firewall and all servers follow best practice rules (limited admin accesses, only required ports open, etc.)

reduce the possible consequences of a successful attack

setup log analyzis to detect illicit access and reduce to time window of an attack
If the attacker could read the environment variable - but cannot execute any command - ensure that the database server is not reachable from the outside of the datacenter
if the data is highly sensitive, you can even protect access to the database even if the web application server was compromised by using an API requiring a previous client authentication and pass the client token to a service appplication server that can do authorization controls. The full defense becomes here:

external_firewall - reverse_proxy - web_server - internal_firewal- application_server

Encryption on the server can only be obfuscation, because the decryption key must be accessible somewhere. It can only harden the task for the attacker, but will not be able to block him.


What is meant by "Vulnerable with: css class selector" for JQuery?

In jQuery you can specify a CSS selector and HTML code with the same shorthand.

This is a selector:

$('#some-thing')

This is HTML that gets evaluated immediately:

$('<svg onload=alert(1)>')

This is a real-life code sample for parsing a selector from the location hash (the URL part after a #):

var x = $('#' + window.location.hash.substr(1));
x.addClass('highlighted').find('div').show();

It's taken from this question and a similar approach is (dangerously) recommended in this SO thread.

See the problem with it? The author's intent was to allow a user-controlled CSS selector, but if you open the affected site as https://example.com/#<svg onload=alert(1)>, you end up with this ambiguous selector:

$('#<svg onload=alert(1)>');

Older versions of jQuery run this as HTML code and thereby create an XSS flaw since the JS event handler would be executed immediately once the DOM node is created. However, newer versions decide that a string which doesn't start with an angle bracket must be parsed as a selector, thereby mitigating the flaw.

From the docs:

  If a string is passed as the parameter to $(), jQuery examines the string to see if it looks like HTML (i.e., it starts with <tag ... >). If not, the string is interpreted as a selector expression, as explained above. But if the string appears to be an HTML snippet, jQuery attempts to create new DOM elements as described by the HTML.

You can read about how this behavior was changed in the discussion to bug #9521.

The page you linked just notes with what kind of selector each version is vulnerable.


SQL table column number changes with injection query?

You are injecting into two different queries (one selecting from category, one from products), which select from tables which have a different column count. When you fix one column count, the other one will not match anymore.

You can't at the same time give different column counts - and you likely can't skip one of the queries - , so a simple union injection will not work.

As errors are displayed to you, you can use a simple error-based injection. If errors were not displayed, you could still use timing- and possibly content-based blind injection (see here for examples for all three). In each case, you would likely want to inject into the first query (it depends a bit on how errors are handled).


It depends on what do you want to achieve: to hide the information that is being sent between the processes or the fact that they are communicating. If your goal is only to obtain confidentiality you can encrypt the information that is being sent between two or more processes.

Prior to this you need to some background information on IPC(on both windows and *NIX), a number of implemented cryptographic primitives(i.e. openssl) and a protocol that actually requires two or more processes to communicate.

An example would be stuxnet.


Internal Update Server in PCI environment

PCI requires, among other things, separation of production and test environments; change controls; and patch management/rollout policies. Patch your test environment first, and place the patch(es)/updates into production in accordance with your shop's change control and patch management policies. Document everything including the URLs or IP addresses at which you obtained your update packages.


Is a safelinks.protection.outlook.com link phishing?

Depending whether this is an organizational email or Outlook.com, it's one of the following:

Office 365 Advanced Threat Protection ATP Safe Links.
Advanced Outlook.com security for Office 365 subscribers

This replaces suspicious links in emails with  https://*.safelinks.protection.outlook.com/* links. If a user clicks the link, it first goes to Microsoft's site that then evaluates whether it thinks the link is safe or not, and then passes the user to the original site or gives a warning. (How ATP Safe Links works.)

What "Safe Links" does is a totally bad practice for several reasons:

It destroys URL visibility. Typically the user decides whether a link is safe or not by examining the URL as schroeder described in his answer. Following this method the user may believe that this is a URL from a trustworthy site outlook.com/ over a secure TLS connection https://. It's even expilicitly mentioned in the URL that it's a safe link and you are under a protection. But the link may be nothing but safe, and the protection may get its detection wrong, redirecting the user to a malicious site. This nullifies all the hard work put for educating the users on how they should handle suspicious URLs.
It's easy to bypass. E.g. Cryptron Security's Security analysis of O365 ATP reveals that it's possible to bypass the ATP Safe Links by

Slightly modified <a x=">" href=" tags the ATP Safe Links isn't recognizing as links
Using <form action= " instead of links (or some other more clever HTML trick)
Showing different, harmless content to ATP servers (list of them is publicly available)
Using redirection services / URL shortener sites

https://www.google.com/url?sa=D&q=https://evil.example.com.

Provides a false sense of security, making people click all links recklessly again.
5 Reasons Microsoft Safe Links Make Office 365 Less Safe adds that the protection is mainly blacklist based and can't handle 0-days / unknown URLs (although it's advertising Avanan's own products, it's a good article on this matter).
Owen Nelson's The Problem With Microsoft's Safelinks adds the privacy problems: both Microsoft and the administrators of an Office 365 tenant can see the original URLs that may contain sensitive information.
As these are not the direct URLs, urlscan.io & virustotal.com won't work for them.


cookie issue with same domain same path but different port

The easiest and clearest solution is simply using differently named cookies (in addition to setting secureflag=true on the secure site cookie), eg. abc and abc_secure. This also makes development and debugging much much easier.


How encryption/decryption of RSA private key by passphrase works?

According to this: https://stackoverflow.com/questions/1774469/how-does-the-rsa-private-key-passphrase-work-under-the-hood the hex string is the initialization vector used by the encryption algorithm.


Is it common for a One-Time-Password system to become unsynchronized?

Disclosure: I work for a company that builds an OTP-based 2FA server.

Yes they can and do become unsynchronized assuming it's not a time based OTP. Assuming we're talking hardware tokens, the biggest reason these things become unsynchronized (believe it or not) is usually because someone's toddler likes to press the button repeatedly. Followed by fat-fingering usernames and/or pins.

If you're using a device that doesn't have it's own power source, e.g. USB-powered, it doesn't get out of sync very often unless you like pressing the button while plugged in. To combat this problem, often times the server will generate 15-20 future iterations of the password after a successful authentication, and future authentications will validate against these values, and then after the next successful auth it will generate another 15-20.

In the event things get totally out of sync you could potentially enter the next 2-4 OTP's generated by the token, and the system will scan from what it thinks is the current key until it finds matching passwords, up to say 100 iterations. This will allow you to resync the key states.


How do SSL certificates become compromised after expiring

There is not much difference between a valid and expired certificate in the SSL/TLS communication. Both case will allow the communication in a safer way and also the same level of data transmission. Even the certificate is expired , the keys are valid until its compromised. Here the point is that the level of trust to the client. But as a Standard SSL protocol part of verification, the client or server need to do.


Having http site load https content - Approach

There is no sensitive data

Are you sure your visitor are OK to share their browsing history? Are your webpages about something they might not want to share?

  Is it ok to have content on https and the site on http. Are there any issues with this approach? Is it recommended?

If your website present the same content with http and https, you must specify a canonical page for search engine to avoid duplicate content problems: https://support.google.com/webmasters/answer/139066

If your redirect http to https you don't have to worry about that.

  Considering that the user sees only the 'http' url, the user still thinks he's on an unsafe site. That doesn't help?

If the main page is http, even if all resources are https, he is on an unsafe website. Some attacker can include malicious java, or fake login page, or ads:

http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/

https://theintercept.com/2014/08/15/cat-video-hack/

  Is doing a force redirect for all the http urls to https the right approach for this?

Yes, it's more secure to always redirect http to https. And better to use HSTS to prevent sslstrip:

http://resources.infosecinstitute.com/mitm-using-sslstrip/

  Related to the query above, is it fine just to have the login page to the CMS over https?

No. It's less secure than having https for all webpages: if you have only the login page with https, you still need to protect sessions cookies:
https://en.wikipedia.org/wiki/Firesheep
and you need to protect webpages that can redirect to the login page:
https://moxie.org/software/sslstrip/
and any webpage where the visitor may expect a login page.
So the only secure way to handle a login, is to use https in the whole domain, with HSTS.

  Are there any other things I need to be aware of?

It's easier and safer to just use https everywhere.
https may even be faster than http : https://www.httpvshttps.com/ https://istlsfastyet.com/
You have access to more features: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins


Is it up to the program developer to implement this?

that's correct, it is up to developer to include CT log support in non-browser applications. CT Logs are required by CA/Browser Forum and this covers only web browsers.


Communicate between two sites both with SSL

A user is "logged on" site A because server A considers the requests from that user to be "linked beyond reasonable doubt" with the user identity. There are several methods by which such a result can be obtained; but usually, some authentication protocol was played (user shows his password) and then some sort of link is maintained, so that for each subsequent request, the server knows that it is "from the same guy as previously".

There are several methods to maintain this link. Main ones are the following:

Each request from the user's browser is a GET or POST which includes as extra (hidden) parameter some authentication token. The token was created by the server when the authentication protocol was executed, and each page sent by the server contains it.
An authentication token was sent by the server to the client, to be sent back to the server with each request, as a cookie.
The server keeps track of the client through the SSL session (when the client reconnects to the server, both client and server agree to reuse the cryptographic elements from a previous handshake, because they both remember the corresponding keys).

The third method is specific to SSL; otherwise, the fact that you use HTTP or HTTPS is irrelevant (except that with plain HTTP, the result would not be secure, but that's another debate).

HTTP cookies are attached to a site name. So if authentication to site A works that way, then the browser will not send the cookie to site B, and the authentication will not be automatically transported from site A to site B.

The first method, though, may work. It "suffices" that authentication tokens created by site A be recognized by site B. But, of course, you don't want other people to be able to produce "valid tokens" out of the blue. So this entails either some form of communication between servers A and B (A telling to B: "hey, I just created this token which authenticates that user), or cryptography (tokens created by A must then contain the user's name and some form of signature or MAC from server A, verifiable by server B).


Strange STP traffic in my network, possible MitM attack?

The classical spanning tree protocol may take up to 30 seconds to process a topology change. During this state, no non topology packets may be forwarded. Are the outages longer than 30 seconds?

Sending STP-notification to all ports may help if someone connects an STP enabled switch twice. Accepting them from any port is problematic because of the DoS vulnerability of the STP that you are experiencing. And it might make arp cache poisoning easier.

Normal computers may act as a bridge because of virtual machines, to allow the guest full network access. If I remember correctly, VMware does send STP notifications by default.

You should talk to the people responsible to operate the student network. They may be able to change the configuration to make it more stable (filter sources, migrate to one of the successors of STP). And they will be able to isolate the owner of that MAC address, at least the switch port it is connected to.


MDK3 deauthentication attack problem: Every station gets disconnected

You can add the mac adresses you want to attack in a blacklist file,  and run mdk3 with the -b flag. Since you used the -w flag,  it disconnected everyone except the target.


If you - for whatever reason - preferred a challenge response protocol that used asymmetric cryptography, you may want to take a look at the work of the FIDO alliance.

This seems however to be an XY Problem. It's not clear why welldefined, secure methods for second factor usage are out of scope for you. Also, as a sidenote: Please do NOT roll you own crypto!

The gist of the linked QA: You are almost 100% guaranteed to make a mistake that can later be exploited.


Best practice for home router configuration

I always do the following for my home gateway (router + modem) or router (if separate, although I haven't seen a modem that doesn't also include a router in at least a decade):

Change administrative password, you can write it on a piece of paper taped to the gateway.
Set security settings to highest level. Usually, this means turning off all external ports and external administration. Why would you want this?
From your LAN, visit www.grc.com and run their IP scanning test. Look for any problems and reconfigure to correct them.
Turn on logging and monitor it from time to time. Watch China, Russia and bot nets regularly knock on your front door.
Kill anything that does pass through from outside to inside unless you really need it, and then consider carefully if you really need it.
If you're running a server, use a DMZ and isolate from your internal LAN. Turn on pass through ports to DMZ server only as needed. If you can't DMZ or run the server there, pass through ports or, consider a simpler proxy server in a DMZ that can handle all incoming connections and check for validity, consistency, security and forwards to internal systems.
Access to your LAN from outside should be by VPN (preferred), ssh (adequate) or both (belt and suspenders).

Assume any port you leave open to the world has a very high likelihood of being compromised, and thereby compromising your LAN. Again, do you really need an open port (unless VPN)?


How practical is it to bruteforce a 10-digit number via URL

About a day

If we're lucky: there's no throttling, we can perform each test with a HEAD request, can perform many tests on a single HTTP connection with Keepalive, and can have many concurrent connections.

In that case we're mostly limited by bandwidth. Say we craft a tight request that is 100 bytes, that means we need to send a total of 100 * 1010 bytes. And lets suppose we have a decent 100 Mbps connection, which will do about 10 megabytes per second. That would take 100,000 seconds - just over a day.

This is best case, in practice there are likely to be issues that prevent it working so fast. We could have multiple systems working simultaneously to make it faster - but at some point we'll overload the server.


Can signing too much compromise a private key?

If the signature algorithm is any good (and used properly with large enough keys which were generated in a correct and suitably random way), then, in practice, the answer is no: having access to many existing signatures does not allow the attacker to forge new ones, let alone recompute the private key.

From a theoretical point of view: most (actually all) signature scheme begin by hashing the message to be signed, and the signature is actually computed over the hash value. Therefore, if the attacker has an existing signature S for message M, which hashes to h(M), and finds a message M' such that h(M) = h(M'), then S is also a valid signature for M' ("valid signature" means "a signature that will be accepted by verifiers"). Therefore one possible attack way is to try many variants of a phony message M' until one is found which hashes to the same h(M) than an existing signature, at which point the attacker has forged a new signature (more precisely, has successfully recycled an existing signature for a new message).

This is a second-preimage attack on the hash function. Having many existing signatures gives more targets for the attacker, which makes that attack easier. But easier is not easy. A "normal" signature algorithm will use hash functions which are strong enough and with a wide enough output that second-preimage attacks are not feasible, for any practical number of targets. To put some figures under it: with a 160-bit hash function (e.g. SHA-1), the cost of a second-preimage attack with one target is about 2160; if the attacker can gather one million existing signatures, cost drops to about 2140: that's one million times easier, but still way too hard (e.g. see there).

Note the fine print, though: I insist on the algorithm being used properly. For instance, consider DSA (or its elliptic-curve variant ECDSA). When computing a signature, you need to generate a random value k chosen uniformly in the [1..q-1] range for a given prime integer q (a new random k is needed for each signature). If the choice is biased in some way, this might be exploited for a key recovery attack. An extreme case is the Sony-PS3 debacle, where they used a fixed value of k, always the same regardless of the message to be signed. This is very wrong: two known signatures suffice to rebuild the private key. More generally, Bleichenbacher has shown (a dozen years ago) that if k is chosen by taking a random string of bits of the same size than q, then reducing modulo q, then the slight bias is sufficient to rebuild the private key from about 263 known signatures (for a 160-bit q).

Of course, in that situation, the problem is not allowing the attacker to see many signatures, but using the algorithm improperly. Implementation of cryptographic algorithms is hard (kids, don't do it at home !).


What is the difference between a certificate, a signature and a thumbprint in case of windows exe/binaries?

This is long. There's an example at the bottom that may help.

A Signature is a bit of cryptographic wizardry where you take some smallish piece of data - almost always the cryptographic hash (something like SHA256) digest of a message, file, or other data blob - and then perform an operation on it (called signing) with a private key. Since only you should ever have access to your private key, only you can produce that exact signature on that data. However, anybody with your public key can verify that signature - that is, confirm that it was made with your private key - and since they have to hash the message/file/blob again to get the digest as it was before being signed, they can tell if the message was modified, too.

In the context of binaries, the process goes like this. Somebody (let's say Microsoft) compiles a binary. They then take that binary and hash it, producing something like a SHA256 digest. They then take that hash and sign it with a private key that only Microsoft has. Now, Microsoft can distribute the file and anybody who has Microsoft's public key can tell that Microsoft signed the file and that the file hasn't been tampered with since it was signed (assuming that is, in fact, the case). The signature can be stored in the file itself, in a little blob at the end which is not included when hashing the file to verify its signature(s) (otherwise, adding the signature would automatically invalidate it!), or the signature can be stored in another file or otherwise transmitted out-of-band.

A Certificate ties an identity to a public key (which, somewhere, has a corresponding private key). You recognize a certificate is valid - that is, the key it contains really does belong to the person or organization it identifies - if the certificate is signed by the (private) key corresponding to (the public key in) a certificate you trust. Signing a certificate works just like signing a binary or any other file: the certificate (including the name it identifies, the dates for which it is valid, the purpose for which it is to be used, and the public key it is tying to that identity and purpose) is hashed, that digest is signed using the private key of somebody you trust, and the signature (modified digest) is placed back into the certificate in a special location. Of course, to identify who signed a certificate, you need their certificate; this is called a chain of trust and can go until you hit an explicitly trusted certificate. Trusted certificates can be ones where you personally identified the certificate and its owner, or where your software vendor did so (such as a Certificate Authority's certificate, or such as the certificate of the vendor themselves like the way Microsoft ships their own certificate as a trusted one in Windows), or something else like that.

In the context of binaries and code signing, a certificate helps you know who signed your binary, and what the signature is supposed to signify (i.e. Microsoft uses a different certificate and signing key when signing a binary that is a core part of Windows Phone and is allowed to run without a sandbox, as opposed to a binary for an app that must always be sandboxed), and how long it's good for. The signature is made with a private key, but is verified with a public key, so if the public key from a given certificate successfully verifies the signature on a given binary, you know two things: the binary has not been modified since it was signed (this would break the signature, and it would no longer verify) and the owner of the secret key (who is probably the entity identified on the certificate, unless you have a reason to doubt the certificate's authenticity) is the one who signed the binary.

For Windows Authenticode signatures, the certificate is usually included with the binary, so you don't have to get the certificate from somewhere else and can just check the signature immediately. The bundled certificate will be signed by some trusted signer, so you know that the binary wasn't just signed by some random schmoe who put a faked-up certificate with it.

A Thumbprint is just a cryptographic hash digest, usually used to identify a key or certificate. For example, let's say you have a blob of signed data that doesn't have a certificate with it. Checking the public key of each of your certificates to see if it can verify that signature would be slow and silly. Instead, the signature will almost certainly have a thumbprint that identifies the public key which can be used to verify the signature. Rather than attempting a computationally-expensive verification with every one of your public keys, you can just check their thumbprints (which are stored in the certificate, along with the key itself, though you can also just hash the key to get one) until you find the matching key, and then use it to attempt the verification.

One other place where thumbprints come in handy with binaries is catalog files. A catalog file has two parts. The first is a list of hash digests - that is, thumbprints - of other files. The second part is a signature of all those thumbprints. This way, you can distribute a bunch of files (some of which may not be binaries, and may not have anywhere standard to put a signature) that you want to make sure the recipient knows are all yours and haven't been tampered with. You just include a catalog (.cat) file that contains the thumbprints of every file, and is signed with your key. If any of the files were modified, their hash digest won't be one of the thumbprints in the catalog. If somebody tries to edit the catalog, its signature won't verify anymore. If somebody tries to replace the signature on the catalog, they won't have the original signer's private key so they won't be able to produce a signature that can be verified with the original signer's certificate.

Example:
Microsoft has a binary they want to sign, a Windows driver. They have a certificate (which they include with Windows) that contains a 2048-bit RSA public key, Microsoft's name, and usage information indicating that it can be used to sign drivers. Because you have Windows, you have this certificate and it is automatically trusted. Microsoft computes the SHA256 hash digest of their driver binary. They then take their the RSA private key corresponding to the public key in that certificate, and use the private key to sign the digest. The modified digest (signature) and the digest (thumbprint) of the public key that can verify it are placed in a special area at the end of the binary. They then publish that binary.

When you download the driver and try to install it, Windows checks for a signature on the binary. Seeing that there is a signature present, it checks its trust store (list of trusted certificates) for a certificate whose public key has the same fingerprint as the one included with the signature. Finding the matching certificate, Windows verifies that the certificate can be used to indicate a trusted driver, and then re-computes the SHA256 digest of the binary (ignoring the part at the end where the signature is). Windows then uses the RSA public key from the certificate and performs an operation with that public key upon the signature. If the result of the operation matches the digest that Windows just computed, it knows that the binary was signed by Microsoft (because only Microsoft has the right private key for that public key), and that the binary hasn't been modified since. It thus determines that the binary is trusted and may be loaded as a driver.

Hope that helps!


How widely used is Elliptic Curve Cryptography?

The best source you probably have, apart from doing a broad scan yourself, is to check the Certificate Transparency logs. Only a few days ago, someone tweeted a statistic from those logs (I could not find a better source for it than twitter, so take it with a grain of salt).


Browser exploits based purely on HTML + CSS

Yes, in the past there have been lots of exploits that only relied on malicious HTML and CSS code.

You are right in that parsing a complex, turing-complete language is potentially more error-prone, giving an attacker more tools to craft an exploit.
Yet, there are many different ways in which the implementation of the used CSS parser or other modules involved in processing the code can be vulnerable.

As an example, take CVE-2010-2752 - Mozilla Firefox CSS font-face Remote Code Execution Vulnerability. This vulnerability could be triggered simply by creating a website with specially crafted CSS font-face rules and yet it had the potential to compromise the host.

The flawed code was located in Mozilla's CSS parser and had a trivial bug: When allocating memory to store the font-face references, a 16-bit integer was used for the index. However, when the actual values were filled in, a 32-bit integer was used instead. This inconsistency led to an integer overflow when a stylesheet supplied an exessive number of external font references. Consequently, an attacker could write to unexpected memory locations and turn the index overflow into an arbitrary code execution exploit.

Since most of the Mozilla core is written in C++, there is no built-in overflow protection and developers are in charge of dealing securely with the memory. A browser written in Python would likely face very different types of vulnerabilities (and also be painfully slow).


Under which conditions can dllhost.exe spawn child process? | MITRE ATT&CK T1191

PS: Looking for events where cmstp.exe is spawned and examining the
  commandline for certain execution flags might seem like a better
  approach but that will not tell us about the final elevated program
  that has been launched.

It depends on the data/visibility you have. If you have visibility to see a process's parent's command line, then one way to detect the behavior is to alert on any process whose parent has the GUID(s) associated with UAC bypass.

As far as the question of how often does dllhost.exe spawn a child process - it is fairly common. So - if you do not have visibility into parent command lines - perhaps the scope could be narrowed to command interpreters, scripting engines, and executables from "non-standard" paths, all whose parent is dllhost.exe.


What's the point of public key servers, if they usually don't require any authentication at all upon upload?

Public key servers are not meant to bring security; they are meant to make the public keys available. Security is achieved, in the case of PGP, through the Web of Trust: signatures from people on other people's keys. A public key server is simply a repository so that you may more easily find intermediate public keys with signatures between yours and that of the intended recipient.

A public key is not deemed secure because you just downloaded it from a key server; key servers have no idea whether the keys they contain are genuine or not. A public key is deemed correct because you could verify sufficiently many chains of signed keys from your own key to that key. How you obtained the keys is not important; they could have come over some HTTP connection, on USB keys, on magnetic tapes carried by camels through the Australian desert, that does not matter. A public key server is thus just a huge camel.

Without the key servers, each PGP user would have, when he sends a signed email, to send along with it a bunch of other signed keys so that the recipient may validate the signature. This would be cumbersome and does not map well to the WoT structure. With a more centralized PKI, like the prevalent model in X.509, sending "helper certificates" is workable; that's what SSL servers do: when a SSL server sends to a connecting client its certificate, it actually sends a certificate chain.


Can a website see the file location of a document I upload?

No!  Almost all modern browsers change the path to something like C:\fakepath\filename.ext in order to protect your privacy.


how much of a security threat would this be?

You would have two types of risks:

There could be a flaw in the server code. This is a generic situation for every server, but a Remote Desktop server is known to be relatively complex, and thus probably has more exploitable bugs than, say, a SSH server. Microsoft themselves offers an additional product called Remote Desktop Gateway (previously known as Terminal Services Gateway) which acts as an intermediate step. The gateway runs a "normal" SSL server, on port 443, and can perform a user authentication, but it is much simpler (and therefore assumed to be stronger) than a full-blown Remote Desktop server, since it does not actually handle the Remote Desktop protocol -- it just forwards it to the actual Remote Desktop server.

Note that among possible "flaws" in Remote Desktop is configuration, in particular with regards to certificates. A basic Remote Desktop server can use various encryption layers, some custom, some encapsulating SSL. A critical point is that, depending on the configuration and on how the user handles it, the client might fail to properly validate the server's certificate (in particular when the server's certificate has been automatically generated and is self-signed). In that case, the client is open to a Man-in-the-Middle attack. There again, the Gateway makes things sturdier, in that it enforces a very Web-like SSL server model which is harder to configure wrong.
If a user is allowed to open a session on the server, on virtue of presenting a matching password, and that password is weak, then an attacker could run a dictionary attack, which means trying possible passwords until the right one is found. This would be an online dictionary attack, and you might be able to automatically notice such an ongoing attack by the huge amount of "failed login" events. However, if the attacker succeeds, then he gets to run arbitrary code on the machine. Privilege escalation on a local machine tends to work (locally exploitable flaws are much more common than remote flaws) so you basically have lost.

The only good defence against weak passwords is to educate users into choosing stronger passwords. As a mitigation measure, you can also restrict Remote Desktop access to some specific users; by default, only members of the local Remote Desktop Users group will be allowed to open a session. Your first step should be to actually decide who is allowed to do that on the machine (As @Hennes suggests, given that the machine is a Domain Controller, the list of people who are allowed to open a session on it should be limited to just the administrator; or you are doing it wrong).

Remote Desktop Gateway is not free and tends to require an extra machine. A cheaper alternative is to deploy a VPN solution like OpenVPN (the core software is GPL, no license needed). This is functionally equivalent. It won't do anything against weak passwords, though.


SQLMap is a great tool if used in correct manner. we need to specify the correct injection point in the complete query of SQLMap
like for example in case of get method used in html form

sqlmap.py -u "www.example.com/file.php?id=1" --dbs //here injection is already specified.

but if its a post method we need to change our query

sqlmap.py -u "www.example.com/file.php" --method="POST" --data"email=ex@ex.com&pass=pass" -p pass --dbs

here pass is the injectable parameter and it will run all its test on this parameter

sometimes header injection exists like for example when the php code takes the ip of the user and doesn't sanitise it

sqlmap -u "http://www.example.com/file.php?id=1" --headers=”X-Forwarded-For: *” --dbs

now the sqlmap will run its test on the headers also i.e X-forwarded-for

SQLMap doesnt perform injections on the headers directly unless its specified.
I think this might answer your query


How long will it take to crack the passwords stolen in the Yahoo hack announced 14 Dec 2016?

Yes, they were likely able to crack many of the passwords in a short time.

From the official Yahoo statement:

  For potentially affected accounts, the stolen user account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (using MD5) and, in some cases, encrypted or unencrypted security questions and answers.

MD5 is a disputable choice for password hashing because its speed makes cracking MD5-hashed passwords really fast. Also, they are likely not salted, since Yahoo would have certainly let us know. (A salt would have helped to prevent the use of rainbow tables while cracking.)

You can see the drawbacks of simple MD5 hashing when you compare it with the Ashley Madison breach in 2015 which leaked 36 million accounts. In that case, they used bcrypt with 212 key expansion rounds as opposed to Yahoo's plain MD5 which is why back then researchers could only decipher 4,000 passwords in a first attempt.

From the article:

  In Pierce's case, bcrypt limited the speed of his four-GPU cracking rig to a paltry 156 guesses per second.
  [...]
  Unlike the extremely slow and computationally demanding bcrypt, MD5, SHA1, and a raft of other hashing algorithms were designed to place a minimum of strain on light-weight hardware. That's good for manufacturers of routers, say, and it's even better for crackers. Had Ashley Madison used MD5, for instance, Pierce's server could have completed 11 million1 guesses per second, a speed that would have allowed him to test all 36 million password hashes in 3.7 years if they were salted and just three seconds if they were unsalted (many sites still do not salt hashes).

So, cracking a large portion of the Yahoo passwords is a matter of seconds (while some stronger passwords will remain unbroken). An exact answer would depend on the available computation power and the password security awareness of Yahoo customers.

1As @grc has noted, 11 million hashes per second appears rather slow. @Morgoroth's linked 8x Nvidia GTX 1080 Hashcat benchmark (200.3 GH/s for MD5 total) is a good resource for more up-to-date measurements.


Avast can hijack email content sent through Frirefox?

You should be aware that most of antiviruses have a full control about the flux of your Internet Browser.
FYI, they even create fake certificates, because they need to decipher the content before sending it to the browser.

Actually, when you install an anti-virus, it copies a top CA cert file into your certificates directory, so all the certificates the anti-virus will create will be accepted.


Is it important to keep my pastebin developer key private?

When you host the app yourself, you obviously use your own developer key.

But don't ship your developer API key in your source code; have people who download and run your code use their own.

That page you linked states clearly that all Pastebin users get a developer API key.

  Everybody using our API is required to use a valid Developer API Key. You automatically get a key when you become a member of Pastebin. Please login to your account, and return to this page to find your Developer API Key.


Consequences of compromised /etc/ssh/moduli

Nothing. The attacker already has it: it is distributed with the OpenSSH source code. This file is used to define the group in which the Diffie-Hellman key exchange may run; the group description is public, it contains no secret value, and can be shared at will. OpenSSH includes several group definitions and selects one at random just because they are paranoid (which is not necessarily a bad thing, for a security product).


MUST Share Personal Info with Windows 10?

Actually, the message isn't from Microsoft Edge; it's from McAfee itself. But you needn't worry: Firefox (and your other browsers) aren't going anywhere.

What's really happening here? Well, Windows 10 makes the new Microsoft Edge browser, rather than Internet Explorer, the new default browser in the operating system. Edge has some promise to it as a new option in the browser arena (especially when it comes to security).  Unfortunately, at this early point in its lifespan Edge isn't...well, to be blunt Microsoft shipped Edge and made it the default browser in Windows 10 despite the fact that it isn't fully baked yet.  One aspect of that: Edge doesn't yet support extensions, and won't until some time in 2016.

And that brings us to why McAfee wants you to not use Edge; to do what it purports to do McAfee needs to run a browser extension in whatever browser you happen to be using.  And since Microsoft Edge doesn't support extensions yet, McAfee needs you to stay away from using Edge or it won't be able to "protect your privacy" while you're browsing.  Thus, the attempt to kick Edge out of your taskbar and do the other things described.

Really, though, it sounds like what you really want to do is to restore Firefox as your default browser, rather than use either Edge or Internet Explorer. Fortunately, you can do this pretty easily.

(Postscript:
BTW, I'm writing this answer in Edge. It definitely has its appeal--the security improvements are quite interesting, and in some ways it's the fastest browser I've ever used.  As a Windows Insider tester I'm probably using it for about half my day-to-day browsing at this point, which I say only to show I don't hold Edge in any kind of enmity whatsoever. But at the same time right now it is undeniably still very, very raw.)


Does using subkeys provide better protection in this instance?

Think of Kerckhoffs's principle. The attacker will know that you derive all file passwords from the single master password. Thus it will make sense for the attacker to try to get the master password, not the derived ones. And if the attacker gets it, all your files can be decrypted. Thus I don't see any difference in the security risks between your scheme and encrypting all files directly with the same password.
This question may look similar to this one, but is actually completely different. In that question there are many parties (applications), each needing its own password. But your case is different. In your case there is a single party that will use them, it is you. That's why there are no key distribution channels (that could be targets of the attacks), there are no other parties (that could be targets of the attacks). Thus there is no sense for the attacker to try to find passwords for single files. The main reasonable target would be the master password. That's why the whole described scheme will not give any additional security and the master password alone will give the same security.
I see the generation of the master password (like using secure PRNG or using good KDF to derive the effective password) as out of scope of this question.