It is an unfortunate situation wherein virus infections are, by nature, insidious. Some infections can be cleaned; sometimes by using specific removal tools, sometimes with manual fiddling about with files and reg keys, sometimes using commercial AV products. Other times they intercept system calls and prevent detection or removal.

The best advice, in the general case, is to either restore to a known good back up or rebuild from scratch. If it is considered reasonable to clean then I would recommend doing it from a live cd of some kind. This provides the best chance to clean off the malicious code without it preventing you from cleaning it.


The software must be installed on a host.

Yes, you need to install it :)

  The software is designed to protect a single host.

Yes, by definition, HIDS focuses on a single host/endpoint.

  The software checks network packets sent to the host against a set of
  signatures.

I prefer to quote you this directly from an official and reliable source in this field:

  HIDS work primarily by monitory system logs and behavior and can be
  signature based (include rule sets that enforce tailored security
  policies) or behavioral based. Most organizations use both types of
  IDSs. They use HIDSs to secure critical host systems and NIDSs to
  secure their network(s).

Regarding the description you gave, the answer is definitely Yes.


Which stream ciphers are supported in am335x cryptographic accelerator?

After all researches I came to know that only CBC, ECB and CTR are supported in the latest linux versions. The driver for OMAP HW accelerator is built properly for CBC mode. In the case of CTR mode it should accept any length of data either for encryption or decryption. But in the case of hardware accelerator it expects data in the multiple of 16 for CTR mode also.

So one thing I can conclude is that the OMAP HW accelerator in am335x properly supports CBC mode only. Except for the data length issue mentioned above, CTR mode is also fine.


When should I generate new public & private keys using RSA?

In general and with a few misunderstandings, what you said is correct.  The main difference being that the ciphertext (e.g. after you encrypt the message with the public key) does not always look the same, RSA introduces some random data and padding that cause the ciphertext produced to be different, even if the plaintext is the same.  This probably won't cause you any issues though, it contributes to security.

Personally, I think the effort involved to get TLS to work would be worth it over implementing your own solution.  However, if you do want to do it yourself...

I wouldn't generate a new keypair for each user.  A single server keypair would suffice.  Distribute the public key with your application and keep the private key on your server.  Use RSA not to encrypt your login data, but to negotiate an AES key, and then use that to encrypt your data.  This is a basic concept used by TLS.  One of the reasons this is done is because the size of the plaintext that can be encrypted by RSA is limited by the bit size of the key.  Generally more than ~240 bytes cannot be encrypted without applying RSA multiple times, which is a poor idea in terms of both speed and security.

Remember to authenticate your data properly, using HMACs or an authenticated mode like GCM.  Otherwise your payload could be modified (not read) in transit.

Don't send the public key to the app, it should be bundled with the app.  If you send the public key over your insecure channel to the app, then nothing stops it being modified in transit.  An attacker could replace it with his public key and then decrypt the traffic (and login details) with his private key.

I say again, TLS would be better and safer than implementing your own, but you seem to think this is not possible.

EDIT:
I say not to send the public key over the network not because it is "dangerous" or an asset when in the wrong hands but because you are sending the public key in plaintext (e.g. over raw HTTP or TCP).  Since anyone could modify this traffic (being able to see it is not a problem), they could replace the public key with their OWN public key before it reaches your app.  If the key is bundled with the app already, then both parties already have their keys (e.g the app with the public and server with the private).

The public key is not useful to anyone for anything other than encrypting and verifying.  It isn't something you need to hide.  You just need to be able to verify that it is the correct public key.  If you bundle this with your app then the security employed by the App Store and Play Store will be enough to get it to the users device with your app.


Web of trust jeopardized because servers getting hacked?

For sites where the security is critical, the key is not a simple password. There's something called Key Input Ceremony for the creation of the key. In this event, three or more people enter part of the key, one after the other, on a special appliance called HSM (Hardware Security Module). The event is attended by legal, audit and compliance staff. It's not something the system administrators create on a file in a server somewhere.

The HSM is responsible for the encryption, and the private key cannot be extracted from it in any way. Extensive anti-tampering mechanisms are employed to detect any tampering attempt and to erase the key if any of its parameters are violated: temperature, voltage, pressure, vibration, to name a few.

In this sites, the SSL encryption is handled by the HSM. The private key is protected inside of it and nobody can extract it.

But there are cases where the private key leaked. In almost every case, the problem was a key poorly handled, or no proper key creation protocol being followed, or dev-mode keys being signed with production certificate requests, or other operational mistakes.


Would this approach allow secure, typo-forgiving password handling?

One method that could be used would be to generate "acceptable typos" upon initial password entry, then to store the hashes of all of these. There are some problems with this: you increase the time required for a password change and for password verification, especially if you're using a slow password hashing method, as usually recommended, and you increase the storage requirements by a potentially variable amount.

Assume that the password used is "Password1!", and that "acceptable typos" are the case of individual letters (or the presence of appropriate characters from pressing Shift and a number), the swapping of adjacent characters, and missing a single instance of a duplicated character (these are not the only possible typos, but from my typos, they're pretty easy to do!).

That means that all of the following would be acceptable:

Password1!
aPssword1!
Psasword1!
Password1! [transposing "s" and "s"]
Paswsord1!
Passowrd1!
Passwrod1!
Passwodr1!
Passwor1d!
Password!1
password1!
PAssword1!
PaSsword1!
PasSword1!
PassWord1!
PasswOrd1!
PasswoRd1!
PassworD1!
Password!!
Password11
Pasword1!

Given any reasonable password algorithm (or MD5), these will all have unrelated hashes:

2b4ae288a819f2bcf8e290332c838148
c435f7c0de60f0f69bce9f9a671e748a
8aed93fca5d9b2416c51fee36b03bc6b
9fbad358027d70c0db81fc23ab483c3c
dbf220c136f6b1f27c30997090da4697
c36fc47e48c2a52e450cd06f60bbd3bf

To verify a password in this case, you hash the input, and check all the possible values. You can even salt the input on an account level, and you only have to calculate one hash. There is a flaw though.

Knowing all of these hashes doesn't actually help an attacker directly, but they can apply the same rules as you did to any password list they have, and should any of the hashes match, they get access to the account - this applies if you use an account specific salt too. The trade-off for login speed helps them too.

Luckily, it's quite easy to defend against that, with a hash specific salt. If you use most implementations of bcrypt, you get this for free:

Password1!:$2a$04$GgLXwKnxLmnLV/UUtbYahuT9L8R.8/SoKAnRKZUyCuEEgfrX5ITLm
password1!:$2a$04$5Ol8psikd7h0Gt/ZWtQAve0PdA/LO4oub/0JMGC5AA/Rsup/3SBbG

Now they have to try all of the modifications against each stored hash. Depending on how you store your passwords, they might be able to optimise which variations they try against each hash, but since they don't know whether the correct password is "Password1!" or "pAssword1!", there is a risk of missing things if they do. However, when someone wants to log in, you need to do the same.

This is the trade-off - if you use a hashing method which takes 100ms to calculate, and need to calculate 1 value, it'll take 100ms to check. If you need to check 10 versions, it'll take 1s of processing time. If you do the checks one by one, you get a timing issue - fast responses mean the original password has been found, slower ones mean it has a typo. If you do them in parallel, you've increased the computing requirements for your system.

Using just the above list of "acceptable typos", you get a variable number of potential passwords. For "Password1!", that means you're storing 21 hashes, one of which happens to be a duplicate of the original password. If you require constant time output when logging into your system (this is a good thing), you either need to be able to calculate all these hashes in a given time, or to delay every login to the time it would take to calculate all the hashes for the longest password you support. If you don't, you've made a password length oracle.

There are hashing methods which allow for similar input to result in similar hashes, but these don't tend to have desirable properties for hashing passwords. They are generally optimised for finding similar parts of large data structures, so are high speed, meaning that large numbers of potential passwords can be tried quickly. They, by definition, don't have an avalanche effect, meaning that a potential attack could try common passwords, then pick the "closest" hash to the ones found for additional mutations. If an output hash from a mutation is "closer" to the stored ones, the input is also closer. With a cryptographic hash, even a fast one, changing a single character in the input is expected to change most of the output. There isn't a concept of "closer" in terms of output, so an attacker can't do better than random changes, hoping to get a match.

If you avoid the hashing issue completely, and go down the HSM route, it might be feasible to have a HSM which stores plain text passwords in an unrecoverable way, and which could produce responses of "original", "typo" and "no" using classical comparison methods. This might be acceptable if you allowed some actions to logged in users, but then required the correct password to be provided for high risk operations (e.g. changing the password), but it's not likely to be cost effective for most providers.

It's certainly possible, but there are a lot of potential issues with doing it, and it's unclear whether the UX benefits would justify the effort. It would probably be a lot easier to encourage the use of password manager applications, since they'll avoid the risk of typos in a lot of cases!


Placing IP address in JSON web token or session cookie

I see a few things to think about:

You'd need to make very sure that a login attempt is only valid when
  the client sends you a valid session cookie. Otherwise, the attacker
  can just not send a session cookie and you'll happily generate a
  fresh one for him on every login attempt. That seems to be a hard problem to solve. How do you force an attacker to send you a cookie if he doesn't want to?
Why do you assume that login attempts will all come from the same IP address? What happens if you have an an attack launched from multiple IPs?
What happens if an attacker doesn't try to attack a single user, but tries a whole range of usernames and passwords? This means you won't detect an attack in progress, because there won't be multiple login attempts for any user in rapid succession.

IMO, you can't get around keeping some persistent server-side state about the global frequency of requests to your login endpoint (or in fact to any endpoint), irrespective of who the client seems to be and whether you get a session cookie or not.


What are the circumstances in which it's not foolhardy to have access to your primary email address through your smartphone?

Unfortunately, no one can answer this question for you. You need to formalize your threat model if you want to be able to understand the risks. Start with the understanding that unlimited access to your phone provides access to your Gmail password. You then have to consider who your adversaries are and how likely they are to gain such access to your phone, for example:

Thief - The average thief is likely to steal your phone and just pawn it off if they can't open it easily. This kind of attacker is unlikely to be after your Gmail password specifically, but would still utilize it for their own purposes if they were to obtain it. Protecting against them is as simple as using a strong form of authentication for your phone. Note that a thief could simply take your phone while you have it out and unlocked. It is not uncommon for someone to ask for the time and, when you pull out your phone to check (if you have no watch), they snatch it and run. These thieves are more likely to be able to access your Gmail.
Stalker - A stalker or another unsophisticated attacker who wants access to your Gmail or other personal information may target you specifically. However, they will not be able to easily unlock the phone unless the password is particularly weak (something they might guess).
Nation state - An advanced adversary who wants access to your Gmail would be able to compromise your phone as long as it is powered on, regardless of whether or not it is locked. However, you must realize that this particular adversary might also be able to directly access your Gmail (e.g. via subpoenas). While there are certainly attackers in this class that need your phone to access credentials, you have to decide whether or not they are yours.

If you do not have a particularly sophisticated attacker out to get you specifically, and as long as the content on your email is not so valuable that people will dedicate significant resources to obtain access, then you really only need to make sure that your authentication method is secure (e.g. a strong password), and that you keep your phone locked whenever you are not actively using it. Make sure you keep the software up to date so there are no known screenlock bypasses.


What benefits are there for security architecture being a separate discipline to enterprise architecture?

My first observation is that security is everybody's responsibility.  No one person is going to be able to police an entire organization's codebase.  Security design and enterprise design are inherently different in purpose and goal, but the two should interact closely for best result.  An enterprise architect's goal is to design a system that meets business needs and represents business processes accurately and come up with a consistent pattern for implementing such functionality.  A security architects goal is to design a pattern of security and provide a consistent pattern for it's implementation and enforcement.

In a large environment, the mere scale of these two tasks might merit different people working on them and there could be a slight gain in relation to separation of responsibility between the business process and the security process, but in general I don't see any strong reason why someone with a cross over skill set couldn't do both.  (I say this as an enterprise software architect with a background in security design.)


Yes, this is known as "self-XSS" or "self cross-site scripting".

Some websites now show a warning in the console:

Any code you paste here can be executed on the current page. If you're logged into Facebook, whoever wrote the code that you paste has full control over the current page.


How can I use a MitM attack to modify intercepted contents on the fly? (educational)

Ok, so in order to modify stuff on the fly, you can't just be observing. You have to set up shop in between the server and the client.

In other words, the communication has to go through you. You can do this by pretending to be a router...

netsh wlan set hostednetwork

... etc etc etc

However, I think the best tool for you might be Charles. Set up the proxy and you're good to go. The problem with Charles is it isn't really a free tool. Older versions of it are free though if memory serves.


Are Whatsapp and Signal truly secure and user-privacy friendly?

WhatsApp has a known security design loophole.
The private keys are indeed stored on the user's device. When you install WA on device B, you will be taking ownership of your account again.
At this point, it's not possible to decrypt messages sent to phone A. Unless...
For user experience reasons, WhatsApp will actively re-encrypt and re-send undelivered (one-checkmark ✔) messages to device B with the newly created keys. This is known as resend vulnerability.

WhatsApp asserted the key retransmission process is a design decision — intended to minimize the risk of messages being lost in transit when, for example, someone gets a new phone or swaps out their SIM.

To explain, the following happens. Please note that there is some simplification:

Alice sends text to Bob, who is offline
In order to do so, Alice gets Bob's public key from WA server. Specifically, she obtains a set of keys to use in the future
Alice sends WA the encrypted messages and obtains the first check
Charlie pwns Bob's account, and notifies WA server
WA has still messages pending from Alice that can't be decrypted by Bob Charlie, so informs Alice
Alice will pull the new keys for Bob Charlie. Since Alice has only one checkmark (message sent but not delivered), she assumes Bob never read those messages.
Without user confirmation and before asking for additional identity checks, Alice re-encrypts and re-sends messages to Bob Charlie
Bob Charlie downloads the new messages encrypted with Charlie's public keys
Alice gets double checkmark (or even blue, if Bob Charlie allows)

However, it happens only for underlivered messages. It means that an attacker capable of taking control of the user account (e.g. SIM swap) is then capable of reading all undelivered messages but not che chat history


How is composed “public host key and certificates (K_S)” in SSH_MSG_KEX_DH_GEX_REPLY message? (SSH2 key exchange)

Found the answer myself in RFC4253:

  Signatures are encoded as follows:

  string    signature format identifier (as specified by the
            public key/certificate format)
  byte[n]   signature blob in format specific encoding.

  The "ssh-dss" key format has the following specific encoding:

  string    "ssh-dss"
  mpint     p
  mpint     q
  mpint     g
  mpint     y

  Here, the 'p', 'q', 'g', and 'y' parameters form the signature key
  blob.

Signature formats:

  The following public key and/or certificate formats are currently
         defined:

   ssh-dss           REQUIRED     sign   Raw DSS Key
   ssh-rsa           RECOMMENDED  sign   Raw RSA Key
   pgp-sign-rsa      OPTIONAL     sign   OpenPGP certificates (RSA key)
   pgp-sign-dss      OPTIONAL     sign   OpenPGP certificates (DSS key)


How does XSRF-token per request work? (Angular solution)

Is the plan good?
Your plan looks good to me. Using a CSRF-token is the standard solution to this kind of problem. But you should not feel safe just because some stranger on the internet tells you it looks good - make sure you understand what you are doing and why, otherwise your are bound to make mistakes.
(A minor point: I am not sure you need to change the token at every request.)
So why does it work?
From this old answer of mine:

The attacker fools the victim to visit http://evil.com that contains a form that automatically does a POST to http://bank.com/transfer?to=evilHacker&amount=1000000. If the victim is already logged in to her bank, the cookie with the session ID will be sent like usual by the browser and there is no way for the bank server to know that the victim did not actually intend to transfer the money. Note that this relies on the browser sending the cookie with the session ID to bank.com.
So how can a CSRF-token help? If the bank.com always checks that a random token unique to that session is present in the request, evil.com can not forge the request since the evil hacker running that site does not know what the token is.

But what about XSS?
As you say in your question, this will not help if there is an XSS vulnerability. In fact, there is no CSRF protection that will help in that case, but if you are vulnerable to XSS you have bigger problems than stolen CSRF-tokens to worry about anyway.
So the only thing to do here is to work on your XSS protection.


EV SSL vs TLS - which one is an advanced version

I think there's a mismatch in terminology between the SSL/TLS protocol (messages sent over a network) and SSL Certificate Authorities who issue digital certificates to be used with TLS/SSL and / or other crypto protocols.

SSL/TLS

You are correct that SSL is the pre-cursor to TLS. This refers to crypto configuration in your server with higher versions indicating more modern crypto:

SSL 1.0 (obsolete)
SSL 2.0 (obsolete)
SSL 3.0 (mostly obsolete)
TLS 1.0
TLS 1.1
TLS 1.2

These are settings you configure in your webserver, and govern which crypto a browser will use when connecting to your server. You do need a certificate for your server in order to enable SSL/TLS, but for the most part, any certificate you get from a CA can be used with any version of TLS.

SSL Certificate Authorities

A Certificate Authority issues certificates for use with TLS and / or other crypto protocols like S/MIME email, signing PDF documents, etc. Most CAs market their "web server" type certs as "SSL" rather than "TLS" for historical reasons. Most CAs offer various price points of certificate, usually broken into:

Domain Validated (DV)
Organization Validated (OV)
Extended Validation (EV)

This refers to how much time their humans spend doing background checks to ensure that you do in fact own the that web site that you are requesting a cert for. They check things like: can you post a file they provide somewhere on the site? Does the DNS record for that domain list you as the owner? If the DNS record lists a company, are you in fact an employee with authorization to request certificates on behalf of that company? And so on, with DV certs just doing the automated "can you upload a file?" checks, and EV sometimes requiring face-to-face meetings between you and the CA, and original hand-signed documents from the CEO.

Consequently, browsers display bigger, greener lock icons for EV to indicate to users that the browser is extra confident that this is not a phishing site. (EV certs are where you see the legal name of the company as part of the TLS lock icon). Note that bigger greener locks have nothing to do with the type of crypto or version of TLS used.

Bottom line: The level of certificate you buy (DV, OV, EV) and the version of TLS that you configure your server for (SSLv3, TLS1.2, etc) have almost nothing to do with each other. All levels of certificate use the same type of cryptography, and and all certs are compatible with all versions of the TLS protocol.


Unlike the resource owner credentials,
     tokens can be issued with a restricted scope and limited lifetime,
     and revoked independently.

from http://tools.ietf.org/html/rfc5849

I guess the RFC has also example, but I did browse it entirely. The oauth site also feature some code, maybe it can help you, http://oauth.net/code/


Use the known, trusted algorithm over one that you've made yourself.**

I can't speak for the entropy, but of course it will take more time if you have a sufficiently large number of iterations. It's just a matter of finding that number. That being said, I personally would not use your SHA256-based code.

As has been said in what is probably my favourite answer on security.SE: Complexity is bad. Homemade is bad. New is bad. From that same answer, Rfc2898DeriveBytes is PBKDF2, and PBKDF2:

Has been specified for a long time, seems unscathed for now.
Is already implemented in various framework (e.g. it is provided with .NET).
Highly configurable (although some implementations do not let you choose the hash function, e.g. the one in .NET is for SHA-1 only).
Received NIST blessings (modulo the difference between hashing and key derivation; see later on).

Why would you want to write your own - potentially buggy, potentially vulnerable, definitely unnecessary - crypto code when there is already code written for you that has been tested, attacked, and demonstrated to be good?

Further reading:

Thomas Pornin's fantastic post about password storage
A GitHub repo containing wrapper code for Rfc2898DeriveBytes
A codereview.SE post about the GitHub code


Restrict request to Android and Iphone App only?

HMAC is a cryptographic concept for assuring the integrity and source (authentication) of information.  This isn't really applicable for what you are trying to do.

Really, there's no way to ensure a request is coming from a specific platform, this is because the host receives this information from the client.  A client can send whatever information it wants by manipulating (spoofing) the HTTP Headers, specifically the User-Agent field.

Bottom line, you can not trust user (client) supplied information.


Find hash-function if original and hash are given?

You can certainly narrow the possibilities down by just looking at the hash. MD5 spits out 128 bits and SHA-256, 256 bits. Beyond that, it would have to be brute force.


Can you sniff traffic to ip address from outside of your network?

Any node at any point along the traffic can sniff the traffic, including all the ISPs along the way.

The question, then, is what threats you wish to mitigate? If you what to protect against "small-time" attackers, then any point within the ISP's network is safer and you only have to worry about the ingress and egress points (server, client, local network connections, etc that you eliminated from the threat scope).


Code-signing application from different locations

The important part is the private key to which the certificate is linked. Unfortunately, some widely deployed documentations get it wrong and call "certificate" what really is the union of the certificate itself (which contains the public key and is entirely public) and the corresponding private key (which had better not be public, of course).

In order to keep the private key private, it is best not to copy it in many places. When a private key "travels" between computers, it is normally as a PKCS#12 archive (previously known as "PFX"), which contains the certificate and the private key, and is password-protected. The entropy of this password is crucial for the security of this transit, but, of course, this protects only the key as it is transferred. You are right: the more a private key is copied, the more vulnerable to theft it becomes.

The normal way of doing this is the following:

Each build machine has its own development certificate. Development certificates are certificates which you generate yourself, with a custom CA (which can be some crude usage of the OpenSSL command-line tool). Test machines, on which development is performed, are configured to accept this custom CA as trusted (or maybe signature checks are deactivated altogether).
For production releases, the binaries which are to be signed are transported to a specific, protected machine which contains the real signature key (the one corresponding to the certificate that you bought from the "trusted provider"). Releases don't occur often, so this manual procedure should be acceptable.

Having a free-for-all signature system, accessible and routinely accessed by developers, looks somewhat dangerous to me. A signature with a key which is trusted by third parties is a responsibility: it makes you liable. You should strive to sign things with that key at rarely as possible, i.e. only for releases.


What is the difference between a SIEM and a SOC?

At a high-level, just remember that:

A SIEM (Security Information and Event Management) is a specific kind of technology, providing network visibility in a security context (by indicating suspicious/illegitimate activity through set-up rules and correlation intelligence), and enabling security analysts to act on suspected threats.
A SOC (Security Operations Centre) encompasses the People, Processes, as well as Technology involved in protectively-monitoring a network, responding to incidents, and researching/actively searching for known/unknown threats.


Should I use HTTPS on a domain that will only be used for redirection?

If you don't secure example.com and a user visits that site, a man-in-the-middle attacker can manipulate the traffic and keep the user on example.com, where he can intercept all traffic.

It doesn't matter that your version of example.com redirects to https://www.example.com/. The attacker can change this behavior and offer a HTTP version of your site to the user.


Do I lose the anonymity of a VPN if they open a port for me?

Opening a unique port just for you? Yes, you lose anonymity, even with NAT, because now that traffic on that unique port unique identifies your traffic.

One of the benefits of a VPN is that your traffic gets co-mingled with so much other traffic that it is difficult to uniquely identify users. Your proposal eliminates this benefit.


Firewall design for big enterprise business

'Best' is probably not the right word here, as the specifics vary with needs, however 'standard' industry practice for enterprise level financial services organisations (a good benchmark) includes:

Client network, with segregated access-controlled subnets for specific key assets (usually customer databases, HR data, financial data)

FIREWALL

Multiple DMZ's - usually split either by function or risk profile (eg a DMZ for transactional services, one for remote access for staff, and another for 3rd party connections)

FIREWALL

Internet, remote clients etc

Firewalls should be from different vendors eg Juniper, Cisco, Checkpoint etc. to increase the time an attacker would take to get past them both (would require two exploits)


How to implement reset password for a password manager

To answer your question "So to clarify my question, are there any best practices for recovering data encrypted with a password if that password is lost?", the best practice is you don't recover encrypted data when you loose your password. Because the point of encryption is to not be able to decrypt without the password, being able to do otherwise will weaken your encryption scheme. So you must ensure not to loose the password in the first place, for example by writing it down and placing it into a safe.

For your question "a version encrypted with the users email + some random token generated when the user creates his account, but would this be safe?", the answer is no, that wouldn't be safe. Because you will have to save the token (and the email address or its hash), it's the same as saving the password in clear text.

If you need flexibility, don't encrypt data with a password. Encrypt your data with a randomly generated encryption key, then encrypt this key with a password and save the key in its encrypted form. You can then encrypt the key with other passwords and save it too, maybe elsewhere (in a vault). Keep in mind that the resulting strength of the encryption will be the one of the weakest password used.


SSLStrip does not downgrade from HTTPS. It tries to prevent upgrade to HTTPS.
I think this is a misunderstanding of how SSLStrip works.
The idea is that SSLStrip stops plain text HTTP sites from upgrading to HTTPS. It will not work if you start by entering "https://" in your browser right away.
What it does is that it installs itself as a man-in-the-middles and then transparently forwards traffic largely without changing it. HOWEVER: If the HTTP page contains any HTTPS links then SSLStrip will "strip" these HTTPS links out and replace them with plain old HTTP.
So if your web server does not even speak plain text HTTP, on default port 80 or elsewhere, then you can't upgrade to HTTPS either. And in that case SSLStrip is not the right tool for whatever you're trying to do.


Snort Inline Mode(IPS) Routing Packet Forwarding

IPS seems not to work without a bridge, right? Here is a docker setup that may work.
This is my iptables entry:
111  5788 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0  tcp dpt:8081 to:172.20.238.3:8080


You can't secure FTP.  Remove it and replace with a secure alternative like SFTP if you need file transfer.  The way in which you've asked the question implies that you don't have a valid need for it, that it's probably just on by default.

Depending on what you're running, 'rpm -e pure-ftpd' or 'dpkg -r pure-ftpd' might do for you.


Server Security Through Constant Check-ins

As you mentioned if someone manages to get root access to your server its game over.
The best practices to keep your server safe are:

Strong password policy
Keep it patched all the time
Enforce additional safety mechanisms on the server such as SELinux, AppArmor etc... (assuming this is a linux server?) there is a good list of these on ubuntu's site
Don't install untrusted software and keep the software on the server to the bare minimum
Don't browse the web from the server
Limit remote connections to bare minimum (RDP, VNC, SSH etc...) better allow only local access
Have proper users and group permissions on your server and have everything run in the  least privileged mode needed

The solution you suggested will not defend you server from being breached - it will just mitigate the risk after your security mechanisms have been breached already. This is already a bad enough situation which could lead to harm of losing data and lots of recovery efforts. The idea is to invest in protecting from being breached in the first place. (additionally as you mentioned - your solution is easily bypassed by a serious attacker which will alternate your php code)


How can I force certain the webclient to honor or remember certain parameters from the webserver?

HTTP Strict Transport Security (HSTS), a feature introduced by Chrome (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is a nice move towards security against MITM.

Other options you mention would be sure to break many sites. Requiring secure-flag cookies for instance (and thus ignoring those without?) would break a lot of sites, as would ignoring 302's.


Can network admin detect port scan on a certain host?

Any one with sufficient access to the network traffic can detect this, All you need is the capability to see all traffic and how its routed (to what TCP Port and IP).

The trick is to detect the 'unusual' signature of a port scan over the rest of the traffic (like sequential trying of random ports / specific well-known ports). This can be quite tricky for automation but is usually easy to do for a human.

As to specific who can detect it that is :

everyone in between you and the attacker that can see enough network traffic.
the attacker. obviously
you (the target) since your machine receives all these requests.

As a rule of thumb: Nothing within a network is anonymous / untraceable from within the confines of that network.


Do browser add-ons increase security risk due to possible vulnerabilities

Yes, the more components you have on any process, the more room for vulnerabilities.

In the case of browser extensions, some of them have permission to read all your history, cookies, navigation data and even change code on the pages you access. Some of them don't have vulnerabilities, but are design to inject malicious code.

AdBlock and NoScript are popular extensions, so it's expected to them to be targeted.


Get r and s from ECDSA Signature as two concatenated integers (OpenSSL)

The ECDSA signature is encoded as an ASN.1 structure, which is a SEQUENCE of two INTEGER values. When encoded, the first byte will by 0x30 (which means SEQUENCE), followed by the length, encoded over one or two bytes: if length is n bytes, then it will be encoded as a single byte of value n if n ≤ 127, or two bytes of value 0x81 then n, if 128 ≤ n ≤ 255 (the latter case may happen in case you use a "large" curve like P-521). These n bytes are the concatenation of the two INTEGER values, each with its own tag (a byte of value 0x02), then its length (same encoding; in practice, over a single byte, since it would take a 1000-bit or so curve to need more than one), then the INTEGER value. The value of an INTEGER uses signed big-endian (so you may have a leading byte of value 0x00).

Properly encoding and decoding ASN.1 structures is a difficult art. I don't know if OpenSSL has a public function for that. This function, from another SSL library, converts from ASN.1 to "raw" ECDSA signatures ("raw" means: the two integer values are simply encoded in big-endian and concatenated, both being adjusted to have the same encoding length).


Why is TLS for email not pushed aggressively to the users likes HTTPS?

There are a lot of questions embedded in your "question". I'll try to explain a few if I can. There is also a lot of confusion here between different aspects of security. Certainly there seems to be a fallacy that, because an organisation has a certificate that helps assure you that their website is actually theirs, that means you can somehow provide email security with it. That is simply not true. Web sites and email services are entirely different things, running on different servers and possibly different platforms. Quite probably run by entirely different 3rd parties.

There are two separate parts to Email encryption. The mail itself and the transport between mail systems. The former uses S/MIME or GPG and the latter uses TLS (similar to a website).

If you look at definitions for secure email services such as government ones. You will see that TLS encryption between mail services is a requirement. This is easy enough to achieve using, for example, transport rules in Exchange. Because you typically secure a limited number of end points, this is reasonably easy to manage. Ideally, mail servers would all talk to each other over TLS and mutually authenticate - to do that, the public certificates for the mail servers from each organisation have to be shared with each other. So you can see that even this can get out of hand very quickly without a complex Public Key Infrastructure in place.

On the other hand, to encrypt individual emails is an even more difficult job. The technology is easy enough. Again. it is managing the certificates and keys that is difficult. That is why this is rarely done anywhere as a blanket requirement. Even governments rarely encrypt emails except for the most sensitive information and even then, you are more likely to find an encrypted attachment than an encrypted email since attachments can be encrypted with a simple password which can then be distributed via another channel.

Very little actual innovation has happened on email clients for years. I was hitting my Microsoft contacts over the head about this the other day and encryption is one area that lacks innovation. Everyone seems to be focused on other forms of communication - maybe they think email is "done"? Likely, they think (perhaps rightly) that there is no money in it. So that is one reason you are not getting what you want.

Other reasons come from how you would calculate the security "level"? That is not an easy question and will be different for each person, organisation, mail system, content classification and more. Unless some parties come up with an agreed standard, it is unlikely this could ever just happen.

There is also a third area that impacts on your questions however and that is directly related to controlling at least some forms of phishing, namely emails that appear to come from a legitimate service but actually don't. For that, there are a number of standards that work together: SPF, DKIM and DMARC. All mail services should have definitions for these (they are stored in your DNS). They enable mail services to verify whether an incoming email actually came from an authorised mail server. This is gaining traction across mail services but is not always enforced as yet.

So the bottom line is that cryptographic signatures on emails is difficult because of the need to manage access to millions of certificates allowing verification of the signatures. However, a measure of security is provided at the server level by requiring validation of sending servers which at least gives assurance that the email came from the correct service - which I'm guessing is what GMail is actually doing. This is not generally exposed in mail clients since there is so little development and innovation happening in that area (Google are something of an exception). But on the other hand, if a mail service enforces SPF/DKIM/DMARC, you wouldn't need to see an indicator since only mail from verified servers would get through - though that could still allow spam through, just not from faked origins.


Can a website infect a computer without the user's assistance?

Yes and no. The problem is that as soon as a known security breach exists, the company which wrote the browser books it to patch the hole, so it is hard to find a concrete example.

One classic example of "drive-by download" is being able to write to disk without the user's consent. One such exploit was shown in Safari last year. What's worse, is that that specific security breach also allowed malicious agents to activate an app on the Mac, kinda scary.


Is there an equivalent of an Apple cryptochip in Android devices?

how does Android ensure that the throttling of failed authentication attempts is not by-passed during an offline attack?

Android KeyStores can be hardware or software based previous to android N, which has made hardware KeyStore a MUST in the CTS.
EDIT: In the below I am using the term online attack as something with the property

Online entities can perform additional security checks to make a protocol more safe. For example, an online entity can regulate the number and speed of login attempts (from another SO q)

...rather than being conducted over a remote network. Maybe I am not using it in the common way but to me the interesting property about online attacks is that there is a layer between the attacker and the data being attacked which is not under the attackers control. Whether this layer is a remote webserver or some local hardware does not make much difference in this case, as both can perform rate-limiting, unless the physical chip is attacked / inspected, which would be a completely different class of attack.
This SO answer actually has a definition closer to the one I am using

An online attack tries automated routines providing input to a legitimate system. They are not looking to create an exploit in functionality, but to abuse expected functionality.
An offline attack attempts to emulate the encryption/hashing and requires a known output of that process (i.e., you don't attack the system, you already have the hashed/encrypted password)

If hardware based, private keys should be extractable from the KeyStore without a sophisticated physical attack (maybe an electron microscope or some black box vuln exposed by the TEE/TPM. This is an online attack. You would hope the TEE/TPM implements throttling.
EDIT: I just tested the nexus 6p KeyStore impl and no throttling takes place for general Cipher operations (was seeing if a padding oracle was exposed for RSA). I have not tested KeyStore rate-limiting for the main unlock however.
If software based then with root, the KeyStore blob can be lifted and potentially bruteforced. This is an offline attack and no throttling can take place.
In answer to your question, it cant ensure throttling of an offline attack, by its very nature.


MySQL uses /* */ as a block comment and no code will be executed within this block. What you are looking at is three injections,  and only one will execute depending on the query that is augmented with this SQL injection attack.  This is an efficiency hack to speed up the process of fuzzing a website for SQL Injection.

If the injection point doesn't use quote marks,  then the first sleep payload will execute and comment out the rest of the injection:

(select(0)from(select(sleep(0)))v)/*

if the injection point is using single quote,  then the 2nd payload will execute:

'+(select(0)from(select(sleep(12)))v)+'

Finally,  if the query is using double quotes,  then the 3rd and final payload will execute:

"+(select(0)from(select(sleep(0)))v)+"*/

Aren't compounded injections neat?


Why does Ubuntu make requests to these Amazon EC2 IPs at startup?

The gnome-software process contacts 54.173.79.111 for update purposes, as suggested in this forum thread. There's nothing inherently dodgy about these IPs, they both belong to the  AWS cloud.

That said, you can't guarantee that the traffic is legitimate by looking at the IPs alone. That's because they only indicate that you're contacting some service hosted  in the Amazon cloud (and apparently running on Red Hat OpenShift).

$ dig +short -x 54.173.79.111
ec2-54-173-79-111.compute-1.amazonaws.com.
$ dig +short -x 54.231.40.234
s3-1.amazonaws.com.

(There is also a maintained list of AWS IP ranges where you can look up the addresses.)

The reason why that doesn't verify anything is that 54.173.79.111 is associated with more than just one EC2 instance. For example, hospitalpadreze.org.br and subverticathegame.com also resolve to that same address:

$ dig +short hospitalpadreze.org.br
54.173.79.111
$ dig +short subverticathegame.com                                                                                130
sub-renderedturkey.rhcloud.com.
ex-std-node683.prod.rhcloud.com.
ec2-54-173-79-111.compute-1.amazonaws.com.
54.173.79.111

Verifying the CN of the SSL certificate at 54.173.79.111:443, as proposed by @thel3l, is also not a reliable technique. We don't know if you were actually connecting via SSL, over which ports and for which hostname. Here's a demonstration of how different certificates get served at the same IP:

$ openssl s_client -connect 54.173.79.111:443 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: C = US, ST = North Carolina, L = Raleigh, O = Red Hat Inc., CN = *.rhcloud.com
Hash used: SHA512
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: ECDH, P-256, 256 bits

The certificate is valid for *.rhcloud.com. Now let's try with a different hostname:

$ openssl s_client-connect 54.173.79.111:443 -servername www.cristiansandu.ro -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN = www.cristiansandu.ro
Hash used: SHA512
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: ECDH, P-256, 256 bits

We're getting a certificate for www.cristiansandu.ro instead, although it's still the same IP. With Server Name Indication (SNI) it's expected that the presented certificate doesn't stay the same if you specify a different -servername.


Yes, your ISP is very clearly hijacking not only the DNS for google, but also DNS requests you try to send to outside DNS servers.

You are correct in your analysis that the traffic to Google is not leaving your ISPs network.  Your traceroutes also show that your DNS queries to Google Public DNS, as well as to Level 3's open resolvers, are not leaving your ISP's network.

Furthermore, the DNS A records returned all point to an IP inside your ISP's network, regardless of which DNS provider you query.  i.e., the A record provided is hijacked, as that is not the A record that Google themselves provides, but rather one that your ISP has provided in its place.

It would appear that your ISP is hijacking the actual DNS queries in order to prevent you from circumventing its hijacking of the DNS records.

No BGP tampering is required for them to do this. All they need to do (and likely all they are doing) is route all packets destined for UDP 53 to their own nameservers. A simple setting in their own router.


This is not a platform to solve CTF excercises.
Still I had a look and will give you a hint:

When requesting check_code.php?callback=callback&code=PARAM you pass two arguments.

Your result is callback("Invalid code: 'PARAM'").
Don't focus too much on the code parameter.

It's a very easy CTF task


Cafe's wifi disconnects me whenever I connect my VPN. How?

How does this work

Your VPN uses a server in Private Internet Access public network to be able to work. The fact that those addresses are used by PIA is well known (it's probably registered in the public WHOIS database too). It is probably known to whoever designed that WiFi security.

As soon as whatever routes packets in that café sees a packet directed to any of a largish number of uncool address pools, the originating device is disconnected for security reasons.

One way to do it is with a Linux router box with iptables, fail2ban, and a custom script to send the disconnect command to a compatible router (I think I know how to do that with a D-Link access point, as it has a Web interface that could be scripted via curl; but most APs are probably scriptable that way). Set a limit of, say, 20 packet attempts in a minute to trigger disconnect, and Bob's your uncle.

  and how do I bypass it?

You need to find a service that offers VPN or proxy services, and yet is not blacklisted. Whether one exists, is more than I could say.

If the network uses a whitelist for allowed sites, and a blacklist for sites that trigger disconnection, you might find such a service and yet it will not work - you'll remain connected to the WiFi (not being blacklisted) but unable to navigate (not being whitelisted).

Frankly, moving your custom elsewhere or procuring a cellphone data plan with WiFi tethering both look more promising than trying to bruteforce access.


Can Cipher Suites defined in TLSv1.2 be negotiated by clients that only support TLSv1.0?

It forces clients who report that they support TLSv1.2 to use it, and causes all other client connections, those who only support a maxium of TLSv1.0 or TLSv1.1, to fail.

At this point, unless you know exactly who your clients are and that they do, in fact, support TLSv1.2, (if this is in any enterprise Intranet environment, for instance) I would not recommend this configuration.  There is a large portion of the Internet that does not yet have the level of support required for this to not turn out to be a disaster.


Yes, AES should outperform RC4, if used on a CPU that has AESNI instructions. GCM is also fast, if used on a CPU with CLMUL instructions. On my laptop with an i7-6700HQ, openssl speed -evp aes-128-gcm with openssl 1.1.0e shows 5GB/sec on a single core running at 3.4GHz. Yes, really. I expect three times that performance  if all 4 cores are used (when all four cores are used, it runs at 2.6GHz, so you get 75% of that performance per core, but x4 the cores). The profiler shows the time is spent in a function called _aesni_ctr32_ghash_6x.

RC4-MD5 are nowhere near that at 520MB/sec for rc4 and 670MB/sec for md5, which would be 0.29GB/sec combined.


HTTPS uses TLS, which is Transport Layer Security.  HTTP as a protocol,  runs above the transport layer.  This means that all of the communication made by HTTPS,  including the URL is protected.

Passing the session id in the URL is insecure for other reasons.  For example it exposes the possibility of Session Fixation.  The Session ID  written to paper if a user prints a webpage.  It also defeats the use of HTTPOnly cookies...  This is just a bad idea and its likely that this bank has made other poor choices in regards to security.


Can someone read my email if they have my smtp credentials?

Maybe.

It depends on what controls there are. Credentials alone will not work if:

processes limit which IPs can connect
processes look for anomalies in what is connecting
Multi-factor authentication
the credentials are only for sending and not accessing mailboxes


Hadoop security, isolation, and hardening

It really depends on who you're trying to protect your data from.

I have set up Hadoop clusters that use eCryptfs on each node, to ensure that data can be transparently shared between nodes, but also ensure that all data is encrypted before being written to disk.  This provides a measurable level of privacy and protection, if you're trying to secure data from being vulnerable to physical theft of disks or remote network storage underlying virtual machines in a cloud environment.

Full disclosure: I'm one of the authors, and the current maintainer of
eCryptfs userspace utilities.


No, You can't change CVV at anytime. It is embedded within black strip which resides on back side of the card.

Each credit card has an expiration time, after which, you'll get a new credit card, with a different CVV altogether.


sudo systemctl running a webserver a security risk?

Services like web servers should be run without escalated privileges, exactly for the reasons that you describe in your question.
While it is true that you must be root to run systemctl, the user that the web server runs under is usually another user with lower privileges.  In the case of apache or apache2, the user is is often www-data, apache, or nobody.
For more information on how to see which user apache/apache2 is running as, see https://serverfault.com/questions/125865/finding-out-what-user-apache-is-running-as
For more information on starting/stopping apache/apache2 using systemctl, see https://unix.stackexchange.com/questions/290923/apache-and-systemctl-status


Materials for CEH

The at-home learning options from EC-Council itself were very good when I took it for v6.

Various study guides are available, but don't cover the full extent of the CEH material, so I won't even link to them here.

Other Certifications

CEH (I hold this cert) is an entry-level ethical hacking certification. It shows that you know what various hacking tools are and what they can do. It basically shows that you have 'heard of' ways to break into networks and servers [i.e. "What's Ettercap?"].

Security+ is a more general security certification and covers more ground, but not ethical hacking.

But if you are looking for the 'cream' of ethical hacking certifications (in my opinion), look at the OSCP. It is not as well-known as the CEH, but it requires you to actually hack servers, write exploits, and produce a penetration testing report. Plus it is aimed for those who may not know much before the class (if so, get the 90 day lab option and try everything out).

Practical experience is the best 'certification'. Being able to explain in a single sentence how you HAVE accomplished a task is worth more than papers. Fortunately, there are tons of materials to help you get that kind of experience. So, not matter which certification you go for, make sure you are spending time each week trying out a new tool or technique.

Certifications in General

I know that lots of people look down on certifications, but they are a valuable tool to get an employed position in the area you want to work in so that you can gain on-the-job experience while working with pros who do have the experience. You just have to be honest about what the certification is. It doesn't prove you can do anything, it simply shows you have a minimum body of knowledge. And that has some worth.


Differences between the OpenVPN SHA1 variations in the digest aglorithms

The reason they have the same digest size is because the same message digest algorithm is used.
The difference is what is being 'digested'.

SHA and SHA1 are likely equivalent, and both should provide a 'normal' SHA1 hash (i.e. something you could potentially replicate by running sha1sum INPUT)
DSA-SHA1-old and RSA-SHA1-2 are used for digitally signed digests - the details aren't necessarily relevant here, but basically, this avoids a MITM being able to just replace a payload + digest with something arbitrary (because a key is involved, the MITM would need to know that key to generate a valid signature for a given piece of data).


What config files and logs files of a Linux system (CentOS 7) deserve to be monitored by a SIEM?

I'll answer these backwards in order to hopefully make the reasoning clearer.  With regards to the second question:  the contents of local log files stored on disk should always be considered untrustworthy.  Logs should be forwarded to a SIEM in real-time, precisely to avoid an attacker being able to cover their tracks.  How you can accomplish this:
Traditionally, syslog daemons like rsyslog or syslog-ng would dump system logs under /var/log.  However, CentOS 7 uses systemd as its init system and thus journald for syslog.  What you will want to do is integrate with journald such that its logs are forwarded to the SIEM.  There are several options to do this, such as systemd-netlogd (this solution is unofficially endorsed by Lennart Poettering).  You can read about other options for accomplishing this here, here or here.  Most SIEMs will accept RFC5424-style syslog over UDP port 514.
To accomplish the first, you will need a File Integrity Monitoring tool.  The open source standard is OSSEC (wiki, site, source).  Similar to the above, alerts should be sent to the SIEM as they are generated, rather than being stored on disk - the documentation how to do that is here.
OSSEC already comes with a large suite of predefined profiles for monitoring security-sensitive locations and other possibly interesting security events.  Beyond the defaults, you will want to have a security professional further configure it for specific events or changes they are interested in, and you will also want to have a developer on the project in question work with that professional to also configure it for sensitive modifications specific to the that project.  Plus, it looks better to the client to present a solution which is specific to their project, rather than just a generic one for monitoring an arbitrary CentOS system.
If required, there are also commercial FIM solutions, such as Carbon Black that you may look into.


Specific risks of embedding an HTTPS iframe in an HTTP page

An attacker who can embed a rogue script in the parent page can also simply change the URL for the iframe, redirecting it to an arbitrary location, at which point all kinds of phishing and man-in-the-middle setups are easy. No need to play DNS tricks at that level. That's the main problem with such an HTTPS iframe: you cannot easily know if you got the genuine thing (you have to fire up the browser debug mode to be really sure -- a cursory look at the page source is not ultimately sufficient because scripts loaded from the page can manipulate it at will at the DOM level, so what you seem to see in the source code is not necessarily what you get).

It really boils down to the lack of URL bar for the iframe. For an HTTPS site, the URL bar shows you that proper SSL is in place, with a valid server certificate, and it tells you the name of the server you are actually talking to. Remove the bar, and all kinds of nasty tricks become possible.

On the bright side, an HTTPS iframe, like a HTTPS target URL for a login form in an HTTP-page, is great against passive-only attackers (the kind of attackers who listens to all exchanged bytes but never injects anything on his own). It just happens that believing most attackers to be passive-only has become singularly naive nowadays.

As for user experience, the usual recommendation is simply to make the whole site HTTPS. It is much less expensive, from a computational point of view, than is usually believed. On a general basis, humans are not good at predicting performance issues. Performance is a matter of measurement, not guessing. I suggest that you try it out.

Also, as a user (albeit not necessarily a typical user), I kind of like the visible transition from HTTP to HTTPS. The checkout is about money, and, crucially, about my money. Thus, it is important.


Is there any safe OpenBSD desktop screenlocker?

Altough OpenBSD made some enhancement to improve the security of X11 the problem is the underlying architecture of the X11 system which has no real (i.e. secure) concept of screen locking. This means screen locking is mainly realized by a process which grabs input and has a full screen window and if this process exits (normally or by crashing) the screen is unlocked. The article from Martin Grasslin you already mention describes the problems very clearly and these problem are no different on OpenBSD.

But, if the screen locking process tries to stay simple (like not trying to integrate with fancy desktop environments, show pretty animations...) or at least crash proof and if X11 itself has no real bugs apart from the design problem then screen locking usually works well enough. This is no different between Linux and OpenBSD.


Is checking the Referer and Origin headers enough to prevent CSRF, provided that requests with neither are rejected?

Expanding on the answers of @Sjoerd and @lindon.

Origin vs Referer vs CSRF token

Most likely, the reason OWASP recommends also using a CSRF token, is that at the time when this recommendation was made - a significant portion of browsers did not yet support the Origin header. This is no longer the case, but people are chimpanzees.

In order to preserve privacy, any browser request can decide to omit the Referer header. So it is probably best to only check the Origin header. (In case you want to allow for users to preserve their privacy)

The Origin header is null in some cases.
Note that all of these requests are GET requests, which means they should not have any side effects.

As long as you make sure the malicious website sending the requests with your browser cannot read the responses, you should be fine. This can be ensured using proper CORS headers. (Do not use Access-Control-Allow-Origin: *!)

To prevent "click-jacking", set the header X-Frame-Options: DENY. This will tell your browser that it is not allowed to display any part of your website in an iframe.

The "new" approach

Setting Cookie properties SameSite=lax or SameSite=strict will prevent CSRF attacks. This is a quite new feature though, and cannot be used alone, simply for the reason that not all common browsers support it yet. You can track support HERE.

When the browsers do, people will likely still recommend checking Origin/Referer/CSRF tokens. If they do - without giving a good reason, it is likely because they are chimps.


Maximum number of Requests in HTTP keep alive connection

10000 outstanding requests in a single HTTP connection is certainly evidence that something has gone wrong.  There are three likely possibilities here:

The server has partially crashed, such that it is accepting requests but no longer processing them.
The client is sending requests faster than the server can process them.
Something has changed in the server, and you are no longer able to identify the responses.

Any of these could be the result of an attack or of an ordinary malfunction; a deliberate design change is also a possibility.  You'll need to investigate further to tell which is the case.


var key = 'some_password';

This needs to go.

Using a printable string as the actual key is not a good idea. You're likely only going to be selecting printable characters from the bottom half of the ASCII table which is a very small amount of entropy per byte, and sure this may be for testing but you would do well to look into the complete solution even at this stage.

Even if you're only exploring or practising, old habits die hard. Start secure.

The crypto module provides for a Password-based Key Derivation Function (PBKDF2), that can turn printable strings into pretty good key material as the crypto.pbkdf2 class.


Blacklisting is good if you have omniscient knowledge of every single vulnerability that could ever exist for a single product. I am assuming you do not have infinite knowledge, so you'd be in a constant fight to blacklist the next threats.

A whitelist is good if you have the expected behaviour and inputs for a product. Eg. you expect users to visit the site and input numbers in a text box. You restrict the text box input to numbers only, so all possible exploits involving letters and symbols are explicitly disallowed.

Whitelists can protect you from the future. Blacklists can protect you from the past.


Multiple Passwords Appear to Log Into Single Account on Major Website

Is this a security flaw? Yes!

If so, what should I do with this information?

Contacting their IT department is a good idea. You want to give them time to patch the vulnerability (two weeks is the standard). If the IT department does not respond or fix the issue, then reach out to other people at the company; e.g., upper management. Reaching them by phone is probably the most efficient option, but I'd personally go the electronic route because documentation is important when it comes to such matters.

If, after all of this, still no action has been taken by them to fix this, you have the option of going public. This document should explain that you've tried to reach out to the company but your attempts went unnoticed. Some see going public as a social and ethical responsibility, but you should only do this as your last step. You'll want to contact them privately at first for reasons stated.

Here is some additional documentation that you should read before proceeding:

How to handle security issues of someone else's website
Found a security vulnerability, what should I do?
How to disclose a security vulnerability in an ethical fashion?


Intruder playing games with my home connection?

That's probably nothing to worry about. To achieve these things it is enough that you visit a website where somebody has included an image from some non-existing or no longer existing domain, i.e. something like this in the HTML code of the page:

<img src="http://its_better_to_play_this_game_when_no_one_sees_you.ttcg.com/img.gif">

This way the browser will try to load this image from the given site and for this the browser needs to do a DNS lookup of the given name, i.e. resolve it to an IP address so that a connection to this site can be established and the data received. Since no host with this name exists an DNS the lookup will fail and will result in the log entry you've seen in the router.

In short: nothing to worry about and that's why it's only shown as "notice" in the log file. And this does not indicate some kind of hack against your system.


How does password-append OTP validation work?

The password is not hashed in the application but in the server. The server gets the password+OTP token in clear (protected with HTTPS between client and server) and can extract both password and OTP token from this, then proceed with normal password verification.


How secure is my logged out but not shut down luks HD

If you are using any type of pre-boot /OS level, or per-mount encryption it usually keeps anything protected accessible until you shut down. If you log out, but the system still needs access to application that would otherwise be encrypted that means the data can still be accessed and that it is either decrypted or that the decryption key is still in memory. Session management is usually disconnected from file encryption.

This means that if you had malware running on your system and it was not tied to your user session, it would continue to run even when you are logged out.

From your OP it sounds like you are talking about physical access attacks. If you can connect the locked system to a network or use a usb device which is masquerading as a ethernet controller it may be possible to spoof your real network and to carry out attacks. A good example is PoisonTap.

  PoisonTap produces a cascading effect by exploiting the existing trust in various mechanisms of a machine and network, including USB/Thunderbolt, DHCP, DNS, and HTTP, to produce a snowball effect of information exfiltration, network access and installation of semi-permanent backdoors.

There are other similar implementation, such as Rob Fuller's and BadUSB. You can use an app like USBGuard to prevent these.

Hypothetically, an attacker may also be able to install a more basic keylogger that you may not notice and then they can obtain your password to your session this way with physical access. There have also been live physical memory dumping attacks in the past and new ones may be discovered.

As a result, if you are in an untrusted environment in terms of physical access you should do a full shutdown to prevent any access to encrypted data. See also this post on the topic.


Using unique per-session gpg keys to store backups on cloud storage

But I'm a little confused. If the master passphrase is compromised ("hacked" / guessed / whatever) - all the backups are compromised. It seems like just another level of indirection.

It's not another indirection, it's another lock the attacker have to pick before entering the safe. It's like having lots of small safes, and another safe well hidden somewhere else, with each little safe's combination. The attacker don't know about every combination is unique unless he successfully opens one and tries the same combination on the others, and don't know where the master combination is stored.

The reason to have a symmetrical key for each backup and one strong asymmetric master key is that you will rarely use the private master key, so it can be very long, be stored offline and be well defended. Security is always a trade-off against usability, and in this case, you can dial all the way to security, like splitting the key in lots of segments and use Shamir's Secret Sharing to store it on various places.

The public key will be used every day, but it is not of much concern. You would not paste it on the home page of your site, but you don't have to be paranoid about it either.

Usually, password leaks are due to human error, not failures on the tech side. Having only one key protecting all your backups means you are one mistake away from compromising every single backup. Having multiple keys you can compartmentalize the data, and the errors can be more contained.

  Is my understanding of this strategy correct, and can you detect any gotchas I should take into account?

I believe your strategy is correct. The most important thing you must take into account is to keep the private key well protected, and never lose it. Leaking the private key means all backups can be compromised, losing it makes all backups irrecoverable.


Where do I securely store the key for a system where the source is visible?

How can I provide decent security on this one to prevent someone grabbing the database (by local access - this machine is NOT Internet connected) ?

There is a lot you can do, but most of it is not directly database programming. Because most of this is not programming, it might be out of scope for you. I don't know what you were hired to do or what your background is. If this is out of scope or you don't feel comforatble implementing it, then let your client know your security concerns and recommend they hire a specalist.

Hash the credit card numbers.

This depends on the purpose of the stored credit card numbers. If the number are only used to uniqely identify a customer or purchase then you don't actually need the credit card number, just a value that maps unqiuely to the credit card number. If this is the case then replaces the credit card number with a hash of the credit card number. Some hash algorithms: SHA1, MD5, RIPEMD-128/256.

Delete the credit card number.

If at some point the credit card number is no longer needed, but the rest of the data in the row is, clear the credit card field. If you need to retain some indication of the card, but not for charging, then keep the last four digits.

Break the database into pieces.

If you do not need to access the whole thing at the same time, break the database into pieces you need to access at the same time. If the entries are independent then break it into equal sized pieces. This will limit the damage if one piece gets lost or stolen. Try to load as few pieces at a time as is reasonable. If your application has only a few pieces accessible at a time this will slow down an unauthroized user.

Store the keys off the machine.

There are a few ways to do this. One method is using a cryptographic token. There are USB devices, smart card devices, and software tokens. Software tokens can be stored on any removable media (CD-ROM, DVD, USB flah drive, etc). If you do break your database up into pieces, your might consider using different keys for some pieces, especially if some are used less frequently than others.

'Salt' your key

A salt is a random number typically used with hashed password entries to make it difficult for an attacker who accesses a password database to quickly find all the passwords in the database. PBKDF2 is a cryptographic algorithm which uses a salt and a password to generate a key. Generate a salt (random number) for each row and store the salt in plaintext in the row. Use PBKDF2 or another suitable key generation algorithm to generate a key for then row and encrypt the credit card data using the generated key. The purpose is to make the attacker read the database and generate a new key to decrypt each credit card number.

Limit network access to the system.

You say the machine is not internet connected but I suspect it is still on an internal network. Use the firewall on the system to restrice network access to two or three other systems. If the system needs to connect to more than two or three other systems then you may need to think about moving the database to a different system or making a dedicated system for the database.

Limit user access to the system.

Configure the security policy to allow only a few critical users to logon to the machine. If more than eight people need access to the machine, again that should be a signal that the database should be move to another system or it's own dedicated system. My quick though on eight users: System Administrater, System Administrator alternate, Security Administrator, Security Administrator alternate, Database administrator, Database administrator alternate, Application Developer, Application Developer alternate.

Limit physical access to the system.

This is just the good old fashioned locked door. If it need to be in an area shared with other system try to make it systems that allow access to the same users. If all that is available is a closet or cabinet, just make sure that it has a unique key. A lot of office locks and furnite share common keys.

Limit what users have physical access to the system.

Just because they need to access the machine don't mean they need physical access to the system. Choose who you give keys to, and instruct them not to make copies or lend it to anyone else.


What would be an example of an attack that exploits escape characters?

Consider this query:

SELECT * FROM users WHERE username='$username' AND password='$password';

Assume single qoutes are escaped, but the escape character \ is not. Then, use user\ as username and an SQL expression (OR 1=1 --) as password:

SELECT * FROM users WHERE username='user\' AND password=' OR 1=1 -- ';

Now, the database searches for a user with the username user' AND password=, or where one equals one. The quote starting the password value is now interpreted as closing the username value.


Do we need to set the X-Frame-Options header for JS files too?

No. The reason we need XFO (or the corresponding CSP frame-ancestors directive) is clickjacking. Clickjacking is not an issue for JS or CSS files, so you do not need to set the XFO header for them. But doing so doesn't really hurt, so to save yourself from configuration mistakes you might as well set it for all resources. It's simpler that way.

It sounds like you are setting the header from the HTML file? If so, here's a note from OWASP:

  Meta-tags that attempt to apply the X-Frame-Options directive DO NOT WORK. For example, ) will not work. You must apply the X-FRAME-OPTIONS directive as HTTP Response Header as described above.


SSH Tunnels for Securing IoT Sensor-to-Server Connections (Many to One)

Using ssh instead of https will probably cause some maintenance headaches. There could be a firewall between your devices and the server (say at the APN exit or at your company's entrance) that will block ssh access. Even if there isn't, allowing ssh access to the server means, well, allowing ssh access to the server with all the risk that opening up shell connections entails. Any logging of the ssh port to look for bad actors is going to be completely overwhelmed by the IoT devices' connections. Presumably you're going to lock down the ssh access pretty tight, but any mis-configuration (like to solve an unrelated problem 3 or 4 years from now) will let someone into your server. Use https instead with a server that listens only for specific reports and throws away everything else and you can defend your server better.

Also SSL has a lot of management utilities already built in, like being able to revoke certificates. If you try to use SSH you'll just end up DIYing a lot of this as you realize you need those features; just set it up right the first time. Whoever comes after you (or you in 5 years when you get called back to maintain this system) will thank you for it!


Create client certificates using signed certificate

Your CA issued you an intermediate CA cert if:

they have provided you a certificate that has the CA extension set to TRUE (with or without a depth)
they have provided you a certificate that has suitable keyUsage extensions, that is keyCertSign and cRLSign (see https://superuser.com/questions/738612/ddg#738644)
you control/own the private key that matches the subjectPublicKey of the certificate

If that is the case, unless they have introduced other restrictions (such as NameConstraints - see https://tools.ietf.org/html/rfc5280#section-4.2.1.10 and https://serverfault.com/questions/670725/is-it-possible-to-restrict-the-use-of-a-root-certificate-to-a-domain), you should be able to use the intermediate CA to issue client certs if you want to.
There may be policy/contractual reasons why this may not be true.

I suspect such a certificate would be expensive, but I don't have any references I can point to.

That being said, it should be noted that for client certificates, there is no fundamental requirement for the CA issuing client certs to match the CA issuing the server certs.
It is entirely possible to use an internal CA for your client certs, and an external one for e.g. your public facing webservers.


Your description of the handshake seems to indicate that the client and the server conducted the handshake completely, and then the client dropped the connection. This means that "something" was not right from the client's point of view. There are mostly two possible candidates:

The certificate sent by the server is not "proper"; the client decided that some user validation is necessary. The client completed the handshake so that it may reopen the SSL session with a faster "abbreviated handshake" (reusing the negotiated "master secret" without having to to the asymmetric crypto again), but closed the connection so as not to keep resources open on the server while the human user makes up his mind (the meat bag is slow).
The Finished message sent by the server (that's the "encrypted handshake message") contains an incorrect value (from the point of view of the client) due to some bug (probably in the client). This is not a very probable occurrence.

My guess is that you are in the first case: the server uses a certificate chain which is "not good" for the client. Usual culprits:

The server certificate chain does not link up to one of the "trusted roots" of the client (depending on the library used on the client, the list of roots can be in several places).
The server name, as expected by the client (the one in its URL) is not matched against the names in the server's certificate.
The client clock is wildly off, so it rejects some certificate which is, from its point of view, either issued "in the future", or long expired.


is it possible to bypass cookie protection to perform a CSRF on HUAWEI HG531 v1 router?

By default, XMLHttpRequest does not include cookies. Use withCredentials to send cookies along.

As an alternative, you can create a HTML form and submit that with JavaScript. This sends cookies along by default.


Let us review the threat:
MiTM - SS7 attack to retrieve the SMS for Authy.
If that scenario happens, the attacker will have a grasp over your encrypted tokens meaning that the attacker needs the password (or a flaw in the encryption algorithm, which is less likely since they use industry-standard algorithms)
in order to decrypt them.

In such a case, the password complexity will determine how long it would take to recover to tokens.
However, I agree that they could have enhanced their authentication mechanism (using an additional user/password, secret of a sort) as in the current method, it is easy to abuse SS7 to get the encrypted tokens and perhaps parallelize the brute-force process.


Does OAuth effectively mean allowing an app to do everything as me?

Yes... if you give it permission to do so.

An OAuth access token has as much power as you give it. Usually, you get asked how much privilege you want to give through that access token at the moment you log in with the OAuth provider. If you decide to give full access to everything then, yes, the application that receives the access token can do anything as if it was you.

It's similar to giving a temporary set of key of your house to a complete stranger that you meet on the road. Still, the saving grace is that it's temporary (usually) and that you can revoke it. In that way, OAuth is still much better than simply giving your username/password to a 3rd party application when you want it to access your information.

OAuth still protects your password and the 3rd party application is nearly always more limited in what it can do with an access token than if it had your real password. This is where OAuth shine and why it was created; giving limited access to your private information for a limited period of time with your consent (and often your ability to revoke that access).

Conclusion

At the end of the day, if you decide to trust malicious application, there is nothing that can save you. BUT, trusting a malicious application via OAuth is much better than giving it your password.


Padding oracle - Vulnerable Version of ASP.NET

I would suggest running a virtual machine with external network disabled, and install a fresh OS from an old ISO image which predates the fix. Disabling external network prevents automatic installation of updates; it also blocks "Windows activation" so you will have only a few days or weeks to try it (but you can "stall" the clock between runs: since the VM has no external network, it has no way of cross-checking its knowledge of the internal clock).

If the VM technology is VirtualBox, use "Host-only networking" as described in the manual. This will allow your own desktop system to access the server in the VM.


loop-aes or dm-crypt for linux hard encryption?

That's not entirely correct.

If you use dm-crypt by itself (without LUKS) then no key information is stored on the disk, and the key is re-derived every time you enter the passphrase.  This isn't really any different from loop-aes.

Using dm-crypt With LUKS, your passphrase is used to encrypt the master key, and the encrypted master key is then written to the disk in a key slot.  Since there are multiple key slots, the master key can be encrypted for different users, each with a unique passphrase.

Since the master key is encrypted before being written to the disk, you would still need to break the encryption on the key in order to use it.

Personally, I don't consider this a significant risk, and use dm-crypt with LUKS on all of the systems I am responsible for.

You can read more about dm-crypt (with and without LUKS) in the cryptsetup FAQ -


I saw a weird url in my logs, dunno how to proceed

This isn't a sign of anything to be concerned about.

As a general rule of thumb you should expect to find all kinds of strange URLs in your logs.  This is the normal "background noise" of the internet.  In essence, shortly after a server becomes accessible to the internet, automated bots will automatically start scanning it for any number of well known security vulnerabilities.  In short, if you were to nuke your server from orbit anytime something strange showed up in your logs, you'd have terrible uptime.  99% of the time the exploits that are being attempted are not even applicable to your particular technology/framework.

In this particular case this doesn't even look especially harmful, although it is possible it is targeting some vulnerability that isn't the usual SQLi or XSS vulnerability.

I would say the main take away from this should be that good application security is very important on the internet, but you certainly don't have any reason to worry on the basis of just this.


Encryption laws in India -- is it allowed to use ssh and VPN?

Professor Koops's excellent summary says that ssh and VPN are legal to use and bring into the country, but that you are required to provide your passwords and encryption keys to the authorities if they ask for them.

However, as a general rule, you should trust neither my nor the Professors advice and instead consult a lawyer, in India, who specializes in this area.

(Your lawyer in your own jurisdiction will have ways to find one.)


Are there any risks to matching user-supplied regex against user-supplied inputs?

Regex can become an incredibly slow operation in Python 3 because python's re module doesn't build a DFA in the background and instead uses recursive backtracking.  This means that the regular expression will take exponential time rather than linear time when applied to a string.  An attacker could construct a regular expression that takes the maximum amount of time to complete by abusing recursive backtracking which can result in a DoS attack if the time to process these regexes is much slower than the possible frequency of requests.

To mitigate this problem I suggest using NFA compiling to DFA regex implementation which you may have to create yourself or find as a module somewhere. Did some preliminary searches and didn't find much to report.


caught email exploit attempt -- info requested -- mail to root+${...}@host

This appears to be an attempt to exploit the recent Exim MTA Vulnerability,  CVE-2019-10149.

There is a patch for Exim4 to address this issue.

NIST Reference:

https://nvd.nist.gov/vuln/detail/CVE-2019-10149


Signature in ECDSA-signed X.509 certificates

The format you mentioned is the ASN.1 type ECDSA-Sig-Value as specified in RFC5480: Elliptic Curve Cryptography Subject Public Key Information:

ECDSA-Sig-Value ::= SEQUENCE {
     r  INTEGER,
     s  INTEGER
}


The standard method for verifying "Blind" SQL injection attacks is the WAITFOR Flow Control element.

WAITFOR DELAY '00:00:5'; - for example, this will wait 5 seconds before returning. Assuming the operation is synchronous with the code, if you see a 5 second delay before a response, you can verify that the injection is working.

You can read more on Blind SQL Injections on the OWASP Website.


Completely mimimise the possibility of my web hosting account being hacked

The security of your Web server will entirely depend on the skill and commitment of the system administrators, both for the operating system and for the Web server software itself. It does not really matter whether the sysadmin is you or someone else; what matters is that the configuration is under control and security updates promptly applied.

Out of personal experience, I would recommend as OS one of the mainstream Linux distributions, e.g. Debian, Fedora or Ubuntu -- which one does not matter much as long as you regularly check for updates and apply them (by "regularly" I mean "on a daily basis"). The *BSD systems are also worthwhile alternatives (FreeBSD, NetBSD, OpenBSD) but they usually have less support from hosting services, and they require a bit more in-depth knowledge of what is going on in the OS entrails (however, their somewhat simpler, more traditional internal structure makes acquisition of such knowledge a bit easier than the Linux case). The relatively smaller user base of the *BSD systems also makes them less likely targets for attackers -- that's "Security through Attacker's Incompetence", which is even less reliable than "Security through Obscurity", but still works in practice.

If your are not the sysadmin of the Web server system, as you hint in another comment, then you rely on the actual sysadmins to do their job properly. This is one of these cases where you tend to get what you pay for. Luck will play a large role in that matter: when using shared hosting, you are nominally isolated from other customers of the same system, but in practice perfect isolation is not a given. Fortunately, most people are honest, as the continued existence of civilization tends to demonstrate.

For your access passwords, what matters most is that you use only "clean" machines. The longest password or the best "key file" on a USB stick will not save you if you type it or insert it in a compromised desktop system. Keeping a desktop system "clean" works along the same lines as keeping a server "clean": be wary of what you install, check for security updates. You do have a few extra possibilities with desktop systems; for instance, you could boot a "secure" system of a USB stick (or a USB external harddisk), without touching the internal hard disk. That way, you could maintain a separation of roles: the OS on the internal disk is for "risky" activities (Windows-based gaming, Web surfing...) while you the USB-booted system would be reserved for Web server administration.

SSL and SFTP are secure technologies, but only act as tunnels. They protect data in transit between two points (e.g. a Web browser on some user's machine, and the Web server) but they do nothing about the security of both end points. SSL and SFTP will not save your skin; it is more a case of not using them would create additional holes to contend with.

Disclaimer: I have presented fairly subjective opinions above about the comparative merits of operating systems. However, I consider that I have both enough experience and a sufficiently inflated ego to be entitled to make such assertions. Other people's experience may differ; I hear that there are some Windows sysadmins who are content with its security. The core assumption, however, is consensual: know your system. You won't get a lot of security as long as the OS and the software remain "magic" in your eyes. Knowledge dispels the magic.


In theory, this can be difficult because both encryption and compression seek to produce high entropy data.  Practical results depend on the specific compression algorithm used; for example, a writeup on /dev/ttys0 claims success in using certain statistical techniques (Chi-Square or Monte Carlo pi approximation) to differentiate certain compression/encryption techniques.


If you can create a process that will run as the victim user, you already have shell access under their privileges.  Anything the victim can do, your program can do.  So you've already won, you just haven't realized it yet!

(One simple example: Why do you need a shell?  If there's something you want to do with the victim's privilegs, why don't you hard-code into your program what actions you want to do?)

If you really want to set up an interactive shell, that's doable too.  I could tell you several ways to do it, but you said you don't want spoilers, so let me just try to give you some hints without answering it flat-out.

You mentioned that running netcat would be one way to achieve your goals, however the version of netcat installed on their system is out of date.  If Alice wanted to install a program for her own use, could she?  If you have access to Alice's account and can do anything Alice can do, does that give you any ideas?
How is netcat implemented, internally?  How does it work?  Could you do something like that yourself?
Let's say you've compromised Alice's account.  What are some ways that Alice could log into her account?  Sure, she could log in with her login password, but what else?
Is there anything Alice could do to give one of her friends the ability to log into her account, if she wanted?  What are some ways she could do that?  If you have the ability to do anything Alice can do, does that give you any ideas for something you could do to get access to her account?
If you run ls -a from some user's home directory, what do you see?  What do those crazy files do?  Does that give you any ideas?

Hopefully that's enough to get you thinking!


Before a piece of software is approved to go into a repo, what security checks does it go through?

where (if anywhere) the appropriate-for-repo line is drawn.

This will probably seem disheartening but a lot of it is simply common sense.  Namely, if no one is reporting a problem then things should be fine.

This isn't as bad as it may sound at first.  There are a lot of phases during which someone can report issues.  To see how these things are done (and to make a you believe this info at something more than face value), let's walk through the process of getting a package into an official repository on some Linux distros.  Although there are dozens of distros out there, we have pretty much only three major base repos from which other distros draw their own repos:

Debian - from which Kali or Ubuntu take packages, and then Ubuntu is spin again into Mint for example.
RedHat - which test packages for inclusion through Fedora (or SUSE which test package inclusions with OpenSUSE).
Arch/Gentoo - that have huge user contributed sets of packages that are included in the main repos if enough people use them (more distros come from her as well, Majaro or BlackArch are spins of Arch, for example).

Let's look a the phases each of these models use, and about extra effort use to check these packages.  But first some general concerns:

General

Software that is used by many people (and I really mean many, e.g. httpd) is also maintained by many people.  Such an environment will first have coding reviews and ways of reporting a user that tries to vandalize the code.

Also, in software that is used by so many people, CVE hunters (e.g. researchers that happen to study that piece of software at the time) would catch a piece of intentional malware within hours.

Apart from people that may look at the source code of the piece of software itself, distros have package maintainers for each package.  If a dodgy feature was pushed into the code repository of a piece of software, and the package maintainer of this package in a distro notices it, he will report it (and not update his package in the distro).

Moreover, adding a new release of a piece of software into a repository (which requires compilation and functional testing) takes 20-30 hours in the extremely optimistic cases (the best I saw recently was Vim 8, was added to the Arch repos 17 hours after the official release).  If there is a known CVE, caused by vandalism, in the next release, a package maintainer will not update a package in the repository (in any distro).

Debian

Debian has debian testing and debian unstable where Debian users can (and often do) use packages that are unstable.  Debian unstable is most often used package by package by the package maintainers.  Debian testing is widely used by people that want the newest software quicker.  It is advised by Debian that packages in debian testing are often not a secure as the stable release with security updates enabled.

The extremely critical software (e.g. httpd or openssl) receive extra scrutiny.  The security team of the Debian developers go through the most important packages (not as far checking every line of code, but tey do a lot of checking) and through pretty much all CVEs.  Their bug tracker is pretty efficient at finding and fixing issues.

As an extra, I am aware of at least one of the members of the Debian security team who runs the CBMC compiler on some packages.

RedHat

Inclusion of package in RedHat (and similar distros) is performed by using an open distro as a testing ground.  For RedHat that is Fedora.  But it isn't that packages can be simply added to Fedora.  By the contrary, there is a good deal of scrutiny over packages to be included: the packaging guidelines of Fedora are thorough.

There is more, before entering the repos for RedHat a package must be well behaved in the main Fedora repos, but to enter the main fedora repos the package should be in the EPEL repos first.  And the EPEL repos are also reviewed according to the package guidelines.

Arch

This is a mix of the two above.  To enter the main repos on Arch the package must have been well behaved (and popular) on AUR.

Yet there is a community security team for CVEs, like in Debian.

Extra notes

Therefore, the package is checked at the development stage by its community.  If the community is small (let's say, only the author), the second person to look at it will be the package maintainer on the distro.  If a single package maintainer or community member raises a red flag about a change, that will likely fall into the hands of a security team (or a CVE hunter) and be dealt with.

All this may still seem sketchy, since it depends on people reporting things.  Yet, if you think statistically, there is little to gain from attacking a package used by 3 people.  Adding a dodgy code change to a package used by millions would be profitable, but then it would need to pass the scrutiny of hundreds looking at it.  Having a single guy reading every line of code going into the distro is likely to be less effective at determining security flaws than the current use of community eyes.

The real danger lies in the language specific (and operating system independent) repositories: akin of pip (python), gem (ruby) or even CPAN (perl).  There are people looking at the packages in there alright, but you can publish a package there that contains malware, and it can go unnoticed for days.