What fraction of web sites are vulnerable?

The most recent study I've seen was back in 2008 by the Web Application Security Consortium [webappsec.org]. The study was compiled from the results of eight separate security assessment projects and had a total sample size of 12186 web applications made up from various industries. The study makes for a very interesting read, but I'll summarize a few of the key points for you here:

There were 97554 detected vulnerabilities of different risk levels.
More than 13% of all reviewed sites can be compromised completely automatically.
About 49% of web applications contain vulnerabilities of high risk level (Urgent and Critical) detected during automatic scanning.
At least 88% of web sites have a serious vulnerability (ranked Urgent, Critical, or High by the PCI-DSS standard).
99% of web applications are not compliant with PCI DSS standard.

Keep in mind these figures are about four years old, and four in internet years is a lifetime (in other words: take them with a grain of salt). That being said, I very much doubt any significant change was made to the percentage of vulnerable sites.

On a slightly related note, if you are interested in other security related statistics, there are two good sites that release reports on a slightly more frequent basis.

One is a DHS sponsored cyber security site [us-cert.gov], whose latest report can be found here (pdf).
Another (which you're probably already familiar with) is the Open Web Application Security Project [owasp.org], whose latest report can be found here.


Manual Testing and Exploitation of an SQL Injection

How about this? http://hackonadime.blogspot.com/2011/07/manual-sql-injection-without-tools.html


This was a programming error on the web dev's end. Not a Django vulnerability.

Django vulnerability lists can be found on the Offical CVE site:

https://www.cvedetails.com/vulnerability-list/vendor_id-10199/product_id-18211/Djangoproject-Django.html


How do hosting providers prevent the compromise of one website from causing the compromise of another one?

This question is a bit broad, but I think an answer that is a little bit broad will still be helpful.  The answer depends on the "kind" of hosting you are talking about.  There are three main kinds which I will break down below, but just FYI the names I use are not necessarily industry-standard names.  The concepts however are pretty common across the board:

Shared hosting (this is the kind of hosting Jeroen talks about in his answer)
VPS hosting (aka virtual private servers)
Dedicated hosting

Shared Hosting

With a shared hosting setup many websites are running under the same instance of the same OS, and different "websites" are typically separated out by having different user accounts on the same system.  cPanel and Plesk are two common software systems that manage such setups (although Plesk can also be used to manage VPS hosting).  As a result, you have to concern yourself with securing two primary aspects of your system: making sure that user accounts are properly isolated (see Jeoroen's excellent answer), and making sure that your container manager (Plesk, cPanel, etc...) doesn't have any weaknesses.  Those tools do occasionally have vulnerabilities of their own, and if someone manages to break into your container management software, they typically end up with root access to the physical server, or in a worst case scenario, root access to all the servers managed by that system.  Also, if you give the users command line access, you have to worry about potential privilege escalation vulnerabilities in the OS itself.

VPS Hosting

With VPS (virtual private server) hosting, the physical server itself is running some sort of virtualization software that then runs any number of "virtual machines" that run a full and separate operating system.  Some examples of tools that manage these kinds of setups are the KVM hypervisor or the XEN hypervisor.  The advantage of this kind of setup is that it gives the end user (aka the customer of the hosting company) full control over their own system.  They can theoretically install any operating system they want, have full root/admin access, and install/manage whatever  software they want.  The hypervisor keeps each virtual OS separated from the rest and completely sandboxed from one another.  Theoretically, it makes it impossible for one compromised host to impact the others at all.  In practice of course, things are not always perfect.  Although (I believe) it is more rare and harder to exploit, the hypervisors themselves occasionally have their own vulnerabilities that can allow a malicious attacker to take control over the whole system (Spectre and Meltdown were relevant for hypervisors - h/t phyrfox).  Like anything else, keeping your systems up-to-date is key.

Dedicated hosting

Some hosting providers offer dedicated hosting, where they basically just manage the hardware for you and provide internet access.  They install an OS of your choice on a server and basically just give you root/admin access.  Obviously this isn't immediately relevant to your question because this is no longer shared-hosting - no one else to impact.  However, they are still inside your network, so proper network access controls are always a must (and this is true for all other hosting instances as well).

Network Management

Edit to add: that last point about network security is worth its own mention.  Regardless of whether you use shard hosting, VPS hosting, or dedicated hosting, a hosting company is inherently giving internal network access to an outside party.  Without clear access controls, this means that anyone using your hosting services can potentially scan other systems on the network for OS vulnerabilities of their own.  For instance, it doesn't matter if your virtualization layer can perfectly isolate the virtual servers running on it if one of the VPS instances can find other instances over the network and gain access via any network-level vulnerabilities in the OS (e.g. heartbleed/eternalblue).  Many of the larger hosting companies will allow you (the person using the hosting) to setup a VPC - virtual private cloud - inside their network to isolate your systems from both the internet and other systems on their own network.  Presuming that their network rules actually work as promised, this gives the end-user additional ways to protect themselves.  Presumably the larger service providers also have active network security that can detect malicious network traffic from inside their own network and shut down accounts appropriately.

In short, the kinds of vulnerabilities you have to worry about depend very much on your hosting configuration.  Of course these days there are a whole new slew of hosting options from the large hosting providers (aka serverless infrastructure) which have their own completely separate list of concerns, but I think the above outlines the major concerns for the kinds of hosting you have in mind.


Where do people who publish "free proxies lists" get their proxies from?

Mostly the hackers will find the vulnerable proxies over the internet by running scanners to find servers lisitining to the web proxies common ports (8080,3128,8000)
For the second part of the question normally any used public IP on the internet will have contact info for the IP owner and you can reach that information from whois.iana.org which will guide you on which site you will find more information related to the IP.
You can contact the IP owner (which is normally ISP)


How to evade a signature to detect "xp_cmdshell" for SQLi?

If you're trying to get around a trivial filter that simply checks if the query contains the string "xp_cmdshell"...
and you're dealing with MSSQL...
and you know that xp_cmdshell is active...
and you know that the user has permissions to access xp_cmdshell...
and you need to specifically run xp_cmdshell, e.g. to prove an exploit, or validate the severity of the finding...

you have several options:

you can obfuscate the "xp_cmdshell" string, in several ways:
DECLARE @s varchar
SET @s = 'xp_' + 'cmdshell'
EXEC (@s)
Or, you can generate if from charcodes... etc.
If what you really want to do is get unrestricted access to the OS, there are other ways besides xp_cmdshell - there are the sp_OA*** set of procs (to instantiate COM objects), assembly access procs, etc.


How Should WiFi Passwords be securely stored on IOT (embedded) devices?

For Windows 7 and above, Microsoft enabled Protected Processes via the RunAsPPL=1 registry change. This protects the LSA from being dumped by even the SYSTEM account. The LSA (lsass.exe process) contains secrets including the WiFi keys and the machine credentials. In order to access these secrets again, the current-logged-in user must have his or her screen locked and unlocked, logged out and back in, or the machine rebooted followed by a successful login. I have tested and verified that tools such as WirelessKeyView will not work when lsass is protected in this way.

This sort of protection is still provided in software (and can be bypassed through kernel or driverspace technology, which has even been seen in the wild with malware such as Uroburos) -- but it is sufficient for many environments and certainly much better than no protection at all. For a hardware equivalent, many are looking at Intel SGX to provide a secure enclave. If the IoT manufacturers can leverage Intel SGX, or a similar technology, then that would be the best location to store shared secrets, such as WiFi passwords, credentials, and cryptographic key material.

N.B., part of this discussion was taken from a talk given by Thomas Dullien of Google -- http://www.slideshare.net/hashdays/why-johnny-cant-tell-if-he-is-compromised -- https://www.youtube.com/watch?v=kG2sISGNZmk


First, the pattern of behavior you're seeing is likely because the malware has detected that it's running in a sandboxed environment. CPU count for your honeypot should be greater than two, if it's not already because most new malware auto terminates if there are two or less CPU cores available, and the processes of your honeypot should not be visible to attackers' software because some of the better written malware will check if honeyd or other well known honeypot daemons are running or installed. An easy option for limiting process/fs visibility is to look up "firejail" and how to setup custom profiles.  Hint: strace output can be parsed and added to firejail profiles to hide/disable listing of host file system and running processes.

Second, look into running a Snort tap between your honeypot and its network connection to capture and fingerprint the attacks network traffic in near real time. I've had good luck with using Raspberry Pis for network monitoring for low cost.

Third, consider using dedicated hardware for your honeypot to make it look more like a legit victim; search term "system on a chip" (wiki has a list of manufacturer) for available cheap options. The one from Intel is the one I'd suggest for this because the architecture looks very close to a legit victims' desktop.

Fourth, look into Metasploit honeypot detection source code for kippo and others to make your honeypot less detectable because there maybe some other clever ways that attacks are detecting their being observed.

Fifth, checkout detection of metasploit reverse shells article using "carbon black" for after honeypot intrusion detection.  Be careful using the tools to hack them back; if you're going to try, do only the minimum investigation needed to identify the criminals.  Even if they attacked you first, it is still a crime to hack them back.


How do you prevent a computer in a network from accessing RDP?

This can be done using Windows Firewall

Open Windows Firewall with Advanced Security
Click on Inbound Rules
Locate the RDP Rule
Right click the rule, go to Properties, switch to the Scope tab.
Add your IP addresses or IP address ranges


Is it important to use separate GPG keys for signing Git commits and for SSH authentication?

Generally, no, mentioned git signatures do not make you more vulnerable to impersonation during SSH authentication. For SSH authentication, the attacker would have to know the private key. And the security of the private key does not depend on how many different messages you sign with it, since it cannot be derived from signatures. That is, as long as the key algorithm is secure, such as ed25519, or RSA with at least 2048 bits.

I also can't see a way how an attacker could correlate the signed git-hashes and SSH authentication in such a way that by signing the one you are signing the other. I don't know if the key exchange mechanism would even allow for this, but even if it did, git hashes contain a random / time based component, and so does the key exchange with an SSH server. So for an attacker to be able to fabricate git hashes on your local system that correspond with real-time SSH authentication requests, and having you sign the same, he would need such a high level of control over your system that there would be more direct ways to access your private keys. If for example, he intercepts the git process, or places a modified version of the executable on your system, then he might as well intercept the key itself.

No, using the same key for git/ssh does not make you vulnerable to impersonation.


Is the action of adding non-official repositories to Linux dangerous by itself?

The adding of the repository itself is not dangerous.
But you will probably do an apt update and apt upgrade (or similar) sometimes after you've added the repository. The apt upgrade will cause any software already existing on the system to be updated with a newer version if possible - no matter if this newer version comes from the same repository as the previous version.

This means if the new repository you've just added claims to have newer versions of some software you already have on your system, then the newer version from the recently added repository will be used to replace the existing software version.
This way backdoors or just buggy software with exploitable vulnerabilities could be added to your system - and this is definitely dangerous.

Note that the contents of a repository can change after you've added it as trusted. This means even if the repository does not currently contain software which you have on your system already it might contain such software in the future. Thus you should not base your trust on the current contents of the repository but decide if you trust everybody which can make changes to the repository.


running firefox as unprivileged user on Linux

AppArmor or SELinux is probably a better solution than running Firefox as a different user.

As you mention, running any kind of new software (including Mandatory Access Controls like these) potentially introduces new vulnerabilities (I'm fairly sure some have been found for SELinux) but I think most agree that the tradeoff is worth it.


How to prevent my web searches showing up as ads on family members device with same wifi connection?

It really depends on how the advertising server are serving the adverts - it could be based on IP tracking, in which case the only way to avoid it would be to use a separate connection, in this case meaning a VPN, Tor, a mobile hotspot etc.  If other devices are using the same account, such as the same Google, Facebook, or Microsoft account, then that would provide another method for determining devices are the same person, but you say that isn't the case.  There is also the possibility that you have installed adware inadvertently which has infected other devices on your network, but if they are different OSes and everything is up to date this is probably least likely.

There is also the possibility that it's a coincidence.  You all live in the same area, may have similar interests, and it is the new year, so showing new year journals might not mean anything.  When it comes to birthdays/holidays though you may want to utilise VPN and private browsing.


There is a training ground just for your purpose:

Nebula 2 is a complete linux distribution (virtual machine) for learning purposes to perform many Privilege Escalation vulnerabilities.

Nebula takes the participant through a variety of common (and less than common)
weaknesses and vulnerabilities in Linux. It takes a look at

 •SUID files
 •Permissions
 •Race conditions
 •Shell meta-variables
 •$PATH weaknesses
 •Scripting language weaknesses
 •Binary compilation failures

At the end of Nebula, the user will have a reasonably thorough understanding
of local attacks against Linux systems, and a cursory look at some of the remote
attacks that are possible.

The fine guys there developed a course system using lessons, each lesson is accessible with a different username and password and each level is directed at a different attack vector.

You can reach further and grab Protostar (basic memory corruption) and Fusion (advanced memory corruption) training virtual-machines @ http://exploit-exercises.com/


OpenSSL: what's the difference between -kfile and -pass?

-k and -kfile are deprecated
The OpenSSL ENC wiki page says this:

-k password, -kfile filename
Both option are used to specify a password or a file containing the password which is used for key derivation. However they are deprecated. You should use the -pass option instead. The equivalents are -pass pass:password and -pass: file:filename respectively.


Company VPN and privacy. (Cisco Anyconnect)

There are a number of ways a VPN can work, although this is often forgotten. For example, a VPN can be used to provide access to resources on a private network which is at a remote location, or to send all traffic from a remote system over a local service of some kind, or just to hide the real origin of traffic.

Split-tunnel mode is often used when a company wants to allow remote users access to resources on the company LAN, but doesn't want to deal with all the remote user's normal web traffic. This works (roughly) by sending requests to specific IP addresses through the VPN, and ignoring everything else. If they want to allow remote users to access resources which have internally assigned DNS names (things like "https:\hr.examplecorp" typically), they need to send DNS requests to a server which recognises these - this will usually be internal. It is possible to configure VPN clients to send requests for specific domains to the internal server, while ignoring others, and sending them to the local machine's configured DNS server, but this is very prone to mistakes, hence most security guides recommended disabling this.

Therefore, it's probably safest to assume that all DNS traffic sent while the VPN software is active is going via the company DNS server. Cisco docs support this:

  a DNS query is first sent via the tunnel and if it does not get resolved, the resolver attempts to resolve it via public interface


Best approach to confirm email within mobile app?

Since this is about security, I would say regardless on how you do it, the security boils down to how many charachters that is suitable to use as "verification code".

However, using a single direct-activation link that is NOT a custom protocol registred as in the above comment, there is a risk that a unaware user clicks this links and inadvertly activates a account that the user did not register.

However, from a usability Point of view: Everyone does not have their email account tied to their phone, so a alternative must be used.

So my suggestion here is:

Have 2 alternatives, where the first alternative is a link like:
appcustom://activate/39734962

But you also provide a secondary means of activating, that is like:
"If you receive your email on a Another device than which the app is installed on, Press "Use Code" and enter  39734962 as code."

In the app, you must verify that the activation code corresponds to the same phone that initiated the activation.
Eg: First user register with email. Server sends a unique token to app, that is saved on phone memory.

On server, you store email, token and activation code.

Upon activation, user enter code or click the custom protocol handler link.
Your app then sends to server: Email, the token that was previously saved, and then code. Server checks all 3 fields match.

This would mean that if the user register, then delete the app from phone, and then reinstall the app, the user would be unable to activate using the activation code the user received. The user would have to request a new activation code.

A good idea is to kick off registration from this Point, so when user successfully has typed the activation code or clicked the link, the user is taken to the registration form to fill in the rest of the details, and where the email field is prefilled and not possible to change (of course you also need to check on server-side that the email field is not changed).

By using such a scheme, you avoid email adresses getting locked up because of malicious or unaware users.

Eg:

1: User fills in Email and press submit.

2: Phone receives token from server. Phone saved email and token in memory.

3: User clicks protocol link in mail or enters the code in the app manually. App sends email, token and code to server. Server validates Email, token and activation code is correct.

4: User is now taken to the registration form where he is asked to fill in the rest of the details, like username, select a new password to use with account, first name, last name etc.
Of course, the link and code in email must remain valid until the registration is actually completed, so if user accidentally abort the process (for example moves out of network coverage), they will be able to continue at a later time.

However, its a good idea to expire activation codes and tokens by time, for example 48 hours is a good time.


How to Protect Webservice on Private Network?

Short answer is "yes - you should worry".

Modern attacks almost always target clients; and once an attacker has a toehold in your network he/she can pivot to any resource the client has access to. He/she may also be able to "man in the middle" traffic on your LAN; or better yet - gain credentials to the switches/routers and sniffers in your network.

So I'd suggest you definitely should use https (TLS 1.2 or better) on the web service. Sessions should also be authenticated: for user convenience you may need to use some kind of session cookie or "single sign on" with Kerberos or similar.

In addition: your database server should be protected. Is there any reason for clients to directly connect to it? Probably not. So use some kind of firewall in front of the database server to limit inbound connections: only your web/application servers and systems management servers need access!

Firewalls on the perimeter are important but they are far from being the only defense you need. For background consider some of the high-profile breaches we've seen in the news recently! Access wasn't obtained by breaking through a firewall - almost always it was obtained by compromising a client that is already inside the network.


What exactly is digested in an S/MIME signated-only e-mail?

From RFC 5652, section 5.4

  The message digest calculation process computes a message digest on
     either the content being signed or the content together with the
     signed attributes.

But you can verify the (cms-)digest of the plaintext by hand:

Save signed mail from Thunderbird as Test.eml
Check message digest: $ openssl cms -in Test.eml -cmsout -print
Cut out plaintext from mail and save to Test.txt
Compare all hashes to digest from step 2: $ lua sha256-hash-finder.lua Test.eml "4db15ae843e3 ... "


Shortening Diffie Hellman key size through pbkdf?

I don't think this is a good idea.

The problem in Diffie-Hellman key exchange is not the size of the generated key (this can be as big as required), but the need to authenticate one side to avoid man-in-the-middle attacks.

And this is the reason to have a public-key component at all - without this, DH could even work anonymously (and works, if you have only passive attackers to fear).

So, my idea would be to use standard (big-modulus) Diffie-Hellman, and authenticate the result with a public-key signature.

But then the problem with small asymmetric public keys is that it is not that hard to derive the corresponding private key from them (in the RSA case, factoring the modulus, in the DSA or Diffie-Hellman case: solving a discrete logarithm).

This needs to be done only once (for each key), and then the attacker can play man-in-the-middle for every following session authenticated with this key.

(Removed the last paragraph about ECC, since it was not really thought through, and I'm now to tired to do it right.)


Do home video surveillance cameras work as deterrents?

Studies show that the deterrent effect of security cameras is minimal.

Moreover, the question is whether are you trying to deter crime in the whole neighborhood or just in your house. If it's the latter, it makes sense to put up a CCTV in your home if other people haven't -- this will likely shift the interest of the burglars from your home to your neighbors'.

If it's the former, hiring a security guard to roam the neighborhood would probably be better in terms of cost/benefits.  A neighborhood watch program might also be effective.

Yet, this largely depends on which country/city you live. The local police, knowing the territory, should be able to give you good advice.


How to securely, physically destroy a hard drive at home?

You want fast and simple?

Step 1: Try and take it apart. If you have the right screwdrivers, great, if not, just go to the next step.

EDIT2: Also use sandpaper on the platters before smashing them. It's very hard to smash into small enough pieces, and very hard to sand afterwards. If you can spend a bit of money, there are also dedicated kits, such as DiskStroyer which provide instructions. Apparently, they also provide a magnet and screwdrivers.

Step 2: Have at it with the biggest, heaviest metal hammer you have. Hit the platters a few times and it should shatter. (EDIT: NB: Make sure you smash the logic board (all the green stuff) up decently as well. Modern HDDs have 32-64 MBs of cache, and SSHDs have around 8 GB, and we don't want anyone to get a single bit)

Step 3: Find a big magnet and go over the disk a few times.

Step 4: Find a really hot flame, and melt the data off. A good gas flame can get up to 1200 °C, easily enough to demagnetise even the toughest materials.

And you're done! Send your now thoroughly unusable drive into the bin, or a recycling center, or whatever else you do to dispose of electronics.

EDIT: To be completely honest, I would do this to an encrypted drive as well, with the logic that any drive needing encryption should be disposed securely to prevent the exploitation of vulnerabilities in the encryption discovered in the future.


How to prevent XSS attacks in ASP web application

There are a few things to do:

HTML Encode any HTML OUTPUT
REF: https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.htmlencode?view=netframework-4.8
Implement a proper CSP. This will prevent third party remote scripts from loading like on the first payload
REF: https://content-security-policy.com/ This won't prevent XSS, but will make the script length limited to that of the field, making payload options limited.
If you have the time implement INPUT validation only allowing expected data like characters and numbers. If you have proper OUTPUT encoding this isn't even necessary, but still is advised to do. The main issue with INPUT validation is that it can be much more easily bypassed than output encoding and more mistakes usually are made here.


What are the benefits to HTTPS between two servers I control?

It's actually hard to make sure that the link between any two of your servers is indeed correct and cannot be rerouted or spied upon. For instance:

Common switches strives, as an optimization, to send packets only on the wires needed to reach the destination machine; however, in some circumstances (in particular if spammed with too many packets from random source MAC addresses) they tend to revet to "hub" mode, in which each incoming packet is broadcast on all wires. In order to maintain the idea that "your network is secure", you must be sure that nothing in your network is compromised.
Machine-to-machine communications are usually initiated by names: server A talks to server B by first looking up B's IP address through the local DNS. A variety of DNS spoofing methods can be used to make A believe B's IP address to be another value, even an IP address in some other place of the world.
While machines are (normally) in closed rooms, wire may run along exposed pathways (e.g. in suspended ceilings, going through less secure rooms) and cleartext data travelling on these wires may be spied upon.

It is possible to have a really secure internal network, but it requires a lot more effort than is usually thought. Enforcing systematic HTTPS between "internal" servers is easier; it is also useful for damage containment (when Bob from accounting inserts into his computer the nice USB drive he found in the parking, thereby surrendering control of his computer to an external hostile entity, generalized internal encryption may help with slowing down the attacker on his way to total compromise of your whole network).

Note that other technologies may also help; e.g. you could make a VPN tunnel (IPsec) between server A and B, and then use plain HTTP within that tunnel. The security model is slightly different (HTTPS security is between applications while a VPN tunnel is between operating systems) but it can work. In practice, HTTPS may be easier to configure.


Why would an attacker use eval as part of a payload?

The way I understand it, eval is often used because it allows flexibility, to run whatever code the attacker wants. It's part of their "web shell", their way to interact with infected servers. I guess eval is just one of the quickest and most flexible ways to interact with an infected machine and make it execute the attacker's code.

// very simple example: in practice often you will also find
// obfuscation, base64 encoding, compression, POST instead of GET, etc.
$command = $_GET['foobar123'];
eval($command);

// request that will likely execute any PHP code on any server
https://www.example.com/index.php?foobar123=code_to_execute_here

Other access methods are probably not that flexible. For example, suppose the attacker has admin accounts in several infected CMS's. Only using their admin account, to run their malicious code they would have to install a malicious extension, and each extension should be coded specifically for each CMS type (WordPress, Joomla, Drupal, etc.). So it looks like it's hard to find a quicker and more flexible method than eval (or similar functions like exec, etc.).


Nesting bcrypt + PHPass for improving the security of password storage in legacy software?

I was initially going to close this as a duplicate of "why-is-hashing-a-password-with-multiple-hash-functions-useless" however you have a slightly more complex case in that you already have a database of hashed passwords.

If you consider your existing mechanism of hashing to be insufficient than you need to migrate to a better solution. That means you need to be able to discriminate between the old and new representation, run the verification mechanisms in parallel and convert the clear text from the old representation to the new. And the only time you get the clear text is when somebody logs in.

Although PHPPass is rather long in the tooth, it does use blowfish (and bcrypt is based on blowfish). So maybe you're not improving the security quite as much as you think.


When are HTTP session cookies at risk over Wi-Fi?

If I'm using websites that do not use HTTPS, but I'm on a WEP-protected Wi-Fi network, are my cookies safe from being sniffed by third-parties?

No.  Outsiders can crack WEP networks almost as if they weren't encrypted at all, these days.  Insiders have even more ease of access.  Even on WPA/WPA2 networks, there are still exploits that enable insiders to sniff the traffic of others on the network.  Lastly, there's always the risk of someone listening in on the wired side of the network where your data is not protected by the encryption used over the air.

  Are cookies only at risk during login, or am I at risk any time I use HTTP?

Your data is at risk any time it is sent in the clear.  Even if the login page itself is HTTPS, other webpages that transfer your session cookie over HTTP can put that account at risk.  You are vulnerable as long as you remain logged in and the website is transferring your data un-encrypted.

The only effective way to protect your session cookies is to only use websites that transfer all data over HTTPS all the time, or use a VPN for everything.  Even then, the VPN is only as trustworthy as the VPN service provider.  There's also MITM attacks against HTTPS, so you've really got to trust the system and network you're on if that's your only protection.

Related:

Ways to secure yourself from Firesheep kiddies and other sniffing
Why is FireSheep such a big deal?


Yes, it can result in a security  issue.It is like any web interface accessible from the internet.If the authentication system is not proper, an attacker might bypass it.

On how to manage access.

Depending on the kind of infrastructure that you have in your network, you can setup a VPN and enable access to the interface through the VPN.( you will use a private IP address to do the configuration)

I am not sure about the ways to block the web configuration entirely.


AES-CTR with PBKDF2 for IV for file archiving at server. Is this ok?

AES-128 for encryption because it's faster and supposedly as secure as -256

Yes and no. If you plan on storing your data for a long time, and you're worried about post-quantum attacks, 256-bit might be the better option. Grover's algorithm reduces the time complexity of cracking a 128-bit key down to about 264, which is likely feasible. For 256-bit it reduces the security bound to 2128 operations which is still likely infeasible.

  CTR-mode because I don't need authentication (as in CGM).

Nitpick: It's GCM (Gallois/Counter Mode).

CTR is a reasonable option, but you really will be open to malleability attacks if someone obtains write access to your device. For example, if you were to encrypt an system disk image with GRUB installed, an attacker could guess the instruction bytes as certain positions in that bootloader area (it's a known position and bootloader code is fairly static across versons) then they could backdoor your bootloader and therefore your OS once you decrypt and restore the backup.

  And because (I think) does not need padding which might open up some for vulnerabilities (as CBC)

CBC vulnerabilities are mostly padding oracles, which mostly only apply in an interactive environment. They're almost certainly irrelevant in backup scenarios like this. If you're looking for a good block mode to use for storage, look into something like XTS or XTX. I don't know if OpenSSL supports them though.

  All stored files have a database record where I store the IV.

Personally, I'd just prepend or append the IV to the encrypted file data.

  I also store the iteration count for the IV so I can go back and recalculate with more iterations if needed.

Hmm. Ok. I don't quite understand why you need PBKDF2 to generate an IV at all.

  Encryption password is hardcoded and stored in server software. Same password for all files.

This is massively insecure. Your solution has zero security as anyone who compromises the server can simply decrypt all the files.

  IV is calculated with pbkdf2. @100,000 iterations, sha256, random 32bit salt.

Why? IVs are meant to be unique, and don't need to be random or secret. They exist only to ensure that encrypting multiple messages with the same key isn't insecure.

  a password is needed for IV calculations as well. Can I use the same password as for encryption?

Irrelevant. Your IV should just be a unique value for each file.

  But I do wonder if pbkdf is really needed in my use case. Encryption/Decryption of files are done at the server in a queue-based manner, i.e. no user interaction is involved. So the need to slow down the hashing process doesn't seem to apply here.

It really is irrelevant. Your IV does not need to be secret, and in many cases don't need to be random either, just unique.

  Or have I misunderstood something?

A few things, it seems. You seem to have invented an overly complicated backup encryption scheme where something as simple as the command line openssl tool could be used (see this StackOverflow question). Don't be Dave. You seem to have a reasonable grasp of crypto concepts, but that doesn't mean you should design your own schemes for anything.


Is it safe to allow www-data to execute privileged commands?

This... is atrocious. The whole point of running Web things as a non-root user is damage containment: in case the Web server process gets hijacked through some vulnerability, at least the attacker won't obtain full control of the machine, since he will be constrained by the limitations of the non-root account www-data. But if you give www-data a way to run every command it wishes to, with the rights of any user (including root), and without any further authentication, then you just lost that damage containment feature.

To be fair, www-data + sudo is slightly better than simply running everything as root, because the going-to-root has to be explicit; therefore, common flaws like a PHP script writing files in improper locations would be harder to exploit. But still, making www-data a member of the sudoers looks like a poor idea.


The WPS PIN doesn't provide enough security to be used in place of the PSK.  As designed, the PIN provides about 23 bits of security, about the same as a four-alphanumeric password*.  The security comes entirely from the fact that WPS is immune to offline attacks, requiring the attacker to make guesses no faster than the AP being attacked will allow.

Essentially, how WPS works is that the AP and computer negotiate an encrypted but not authenticated channel, the computer and AP each perform some math to prove possession of the PIN (note that neither side ever sends the PIN over the encrypted channel), and the AP then sends the PSK and other configuration details to the computer.  Since the PIN is never transmitted, the only possible attack is to repeatedly attempt to prove to the AP that you know the PIN.

If you use the PIN in place of the PSK for traffic security, offline attacks become possible because data derived from the PIN is being transmitted, and an attacker who can record the encrypted traffic can recover the PIN in a matter of seconds by checking to see which PIN would produce the derived traffic.

* As implemented, the WPS PIN provides about 13 bits of security, similar to a two-alphanumeric password.


Chrome: Finding vulnerabilities using AddressSanitizer

That's one way to use AddressSanitizer, but it's not the only way.  AddressSanitizer is just a tool.  It's up to you how you want to use it.

AddressSanitizer is much like Valgrind, if you're familiar with it.  (If you're not familiar with Valgrind, you could think of AddressSanitizer as being roughly similar to Purify, if you're familiar with that.)  It is a runtime tool that monitors the execution of the program and flags a warning if it happens to see something that looks like a memory-related bug.

If you want to use AddressSanitizer to find new bugs, it will be up to you to figure out how to exercise as much of the application as you want and how get good coverage.  You could do anything from "run it once" to "comprehensive fuzzing plus running on a detailed regression testsuite".
Yes, if you want.  It's up to you how you want to generate tests.

I suggest that you read about fuzz-testing.  There are lots of resources.  See, e.g., slide decks from Charlie Miller and the questions tagged with fuzzing on this site.  You might also check out this effort from Google and my experiments on how compilation flags affected fuzz-testing.


How can I allow local pop3 but enforce remote pop3s on my ubuntu/postfix/dovecot OS/MTA/MDA

You don't want to send passwords over cleartext regardless of whether that's a local or non-local user. It's just bad practice and arguments of the "but it's only traversing my trusted switch" kind inevitably lead into a pitfall. You'll make a mistake, or someone else will make a mistake, and suddenly you'll find out months later that somehow attackers were able to sniff your CEO's account password and leak confidential emails to your competitors. Just don't do it.

Besides, part of your premise is incorrect. What postfix is doing via permit_mynetworks is not the same as what cleartext imap would be doing. This configuration option instructs postfix to accept messages for relaying from any local network without requiring authentication -- so no passwords will traverse the unencrypted connection. However, if you allow local clients to talk directly to imap or pop3, that will send passwords in cleartext over the network. Otherwise how would the imap server distinguish user bob from user alice.

If your concern is the overhead of encryption, then it's really not something to worry about these days. AES is really fast, especially if you're using a system with AES-NI support in the processor (and a relatively recent OS that makes use of that in openssl). The performance hit is not worth the headaches of worrying about your users' passwords traversing the network in unencrypted form.


Server Side request forgery (SSRF) explanation

Server side request forgery is a vulnerability where a server connects to an arbitrary host supplied by the attacker.

When testing it is useful to have a host available on the internet where the server can connect to. This will typically not work with your home or work PC, because it is behind a firewall or behind NAT. If the server connects to your IP address, your router will block the connection. Ideally you would have a server with a public IP address, such as a VPS with a hosting provider. Alternatively, you could configure port forwarding in your router.

An alternative is to use a third party service. For example, the Burp Collaborator is a server that will notify you of any interactions with it.

Note that it is not necessarily a vulnerability if a remote server connects to your server. The vulnerability comes if the server exposes information from the local network it is in. Then you can exploit the "server side" of SSRF to navigate the network that you can't normally reach.


Resources for data on security incidents

Ones I tend to draw on:

Verizon Data Breach Report - this is generally considered THE source on data breaches

Krebs Java Security Report - Krebs is very well respected - various studies, of which this is a grand example

WHID Security Report - also very useful

These are all freely available online, and updated versions available annually (or more often in the case of Krebs)


Can my college Wi-Fi admin obtain the serial number/IMEI of my device?

The Wi-Fi admin can only get your MAC Address of your device.

This is needed for you when connecting to Wi-Fi and to get a IP Address.
But MAC addresses can be spoofed.

He cannot get the IMEI number, unless he make you install some software or App on you device.

He also gets your OS version and browser details is via the request Headers of browsers.

Here is a sample. You can see the User-Agent contains the info of your OS.
In my case Windows NT 6.1 and browser information Firefox/38.0.

POST /posts/validate-body HTTP/1.1
Host: security.stackexchange.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://security.stackexchange.com/questions/135142/can-my-college-wi-fi-admin-obtain-the-serial-number-imei-of-my-device
Content-Length: 177

You can spoof this Information as well using various methods.

Edit:

The Above HTTP request headers can be read if you are browsing  plaintext protocols like  HTTP.

When a DHCP request is made the Hostname is sent as well.


Client-Side Hashing to decrease value of password guessing heuristics

On the basis of standard password theory, this shouldn't work as we have to assume the password generation method is known.

I believe what you're asking is this, correct me if I'm wrong.

Your understanding of the standard method.

User 1 - (sent) password1 -> (stored) e38ad214943daad1d64c102faec29de4afe9da3d

User 2 - (sent) Di#aKHn!@ -> (stored) 9187b4dc0f7c7231334546a86984060233304c5e

Dictionary attack on the stored hashes recovers the passwords sent right?

What you want to do is this.

User 1 - (client side) password1 -> (sent) e38ad214943daad1d64c102faec29de4afe9da3d -> (stored) f8fde4f28c22e1a5a6201b6cce363477940cde50

User 2 - (client side) Di#aKHn!@ -> (sent) 9187b4dc0f7c7231334546a86984060233304c5e -> (stored) a893a40df9fc73ab3a9711a34e943f13271170c1

So the password for user 1 is seemingly as strong as the password from user 2, because they are both sending 40 character alpha numeric strings as passwords, and attacks on the final stored hash won't work* because the hash wasn't generated by a dictionary word, but a long hash.

The reason this won't work is again the process is all part of the program logic rather than entropy on the human side. The password cracking simply becomes SHA1(SHA1($pass)) instead of SHA1($pass) or whatever other control you have in place (salting etc). Given the need for repeatability it can't be hashed a random number of times on the client side, it must always be defined.

If I've misunderstood what you're suggesting just let me know.

Edit: To further expand on what I think you're saying re:comments below.

You want to make it so hashing takes X time, where X is the point where it's impractical to run dictionary attacks. You're saying that given the resources of the server, using a slow hash like bcrypt can only achieve a slowdown of time 'Y', which is not enough to get you over the 'X' threshold. You're idea is to use the client CPU as well 'Z', so now you have Y + Z to the point where you are hopefully achieving this 'X' threshold of rendering dictionary attacks useless.

My response would be I doubt there is enough CPU power between the client and server to make this impractical for someone to try a dictionary attack, while still maintaining a usable service. This is because the difference between GPU calculations and CPU calculations are so large.


How is Swatting (Twitch) streamers possible?

This probably has nothing to do with the IP address used for streaming.

Many swatting events are based off of caller-ID spoofed Voice over IP calls using the home phone number of the victim and directed to the local 911 service or it's equivalent near where the victim lives. When these calls reach the local 911 dispatchers a database correlating the physical address to the number making the call appears on the screen for the dispatchers to use. So if anything it's probably more likely that people are simply looking for published phone numbers and spoofing the 911 calls from there.

Note: There are MANY ways to do this, they could also do this from any stolen cell phone and simply make up a story about where they are located.

Due to the increase in swatting events many law enforcement agencies are getting better at tracking the people calling these in and are now prosecuting them.

https://en.wikipedia.org/wiki/Swatting

Keep in mind that people have died from swatting and that this is a very dangerous and illegal act.

http://bearingarms.com/ex-marine-swatted-black-shopper-death-walmart-changes-story/

Ultimately there are many sources where the person doing the swatting could get the information about the victims they are swatting and for someone who knows how to do this it's a relatively trivial to do.

In time as law enforcement gets better at quickly identifying the people who do this one would hope the rate at which this happens would go down drastically.

To answer your secondary question about hiding the streaming IP address take a look at Tor or potentially any number of VPN services.

http://tor.eff.org

In regards to the streaming component, it appears that Twitch.tv requires video to be sent in the H.264 codec.

http://help.twitch.tv/customer/en/portal/articles/1253460-broadcast-requirements

https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Controversies

The H.264 codec itself doesn't contain any geolocation features like the EXIF typically data stored in photos.

https://en.wikipedia.org/wiki/Exchangeable_image_file_format#Geolocation

That said it does appear that several camera vendors area adding geolocation data into their videos and per the twitch.tv website they clearly state "Twitch does not reencode your video after receiving it; whatever is sent to our servers is sent right back out to your viewers."

http://help.twitch.tv/customer/en/portal/articles/1253460-broadcast-requirements

This would imply that if some video camera/mobile device manufacturers were to encode geolocation data into these video streams, or the accompanying audio streams, then yes this information could easily be extracted to provide a physical location directly from the stream.

I will point out that other large image services have explicitly chosen to remove EXIF and geolocation data from photos and videos to protect the privacy of their users.

Twitch.tv is not required to do this but it may be something wise for them to start doing to protect their users in the future, especially if it turns out this is the source of the swatting target selection process.

Another issue that may also come up, albeit less likely, is that geolocation data collected via HTML5 browser clients could potentially also be accessible to others using the website. This may not apply to twitch.tv but may be an issue for other websites. My point in mentioning this is simply that geolocation occurs at several levels (IP/Content/Metadata/encodings/out-of-band-data/browser leakage etc.)and it could potentially be extracted from a number of parts of the communications even if the streaming source IP is not the problem.

It may be worth spending time to see if you can search for the swatting victims phone numbers based on things you see and hear in their videos to determine if it seems like that's how it's happening. Sometimes these things are easier to find than one would initially think.


Are images in the FROM name a risk in emails?

The pictograms you are seeing in the name portion are Unicode emojis. They can be used anywhere there is an updated version of Unicode. To see a full list of the supported emojis for each version of Unicode, look here. You can copy and paste them just about anywhere, and they will display.
These do not contain tracking, they are loaded from your system locally. However, if they are embedded as an image within the body of the email, that is a different story.


How to perform an idle scan against a target using Nmap with a list of zombies?

Put the zombies' IP addresses in a file (say IP.txt).
And let's assume that the target machine

  192.168.88.135

Then you can use a script to automate the scan process.
Something like this

for ip in $(cat IP.txt); do
nmap -sI $ip 192.168.88.135 -p $1 >$ip.txt
done

After saving this script, and giving it execution privileges, you can invoke this script and pass the port you wish to scan to it as a parameter.

For example :

./script.sh 80

This command will attempt to preform idle scan on the target for port 80 using all the zombies you had their IPs in IP.txt and will save the result of each scan in a text file with the zombie's IP address.

I hope i got your questions right cause i still have doubts about whether this is what you want exactly.


Well yes this is possible. Devices will send probes for any network currently in their wifi configuration, which for most users are all the networks they have signed on to in the past. So your home network for example is in the config of your mobile and your mobile will constantly probe that network while wifi is active. You just need to listen for the Probe Requests they send with Wireshark.

If you want to keep track in which networks which device has been, you need to analyze the traffic dump in order to put each device and each SSID into a DB. You can then query the DB for any given device about all the SSIDs it has been connecting with. This will allow you to track them. But there is no tool I know of which automates this.

There's also a nice tutorial for BT/Kali Linux for this: https://blog.rootshell.be/2012/01/12/show-me-your-ssids-ill-tell-who-you-are/

The only way to defend against this is disabling auto-connect on your device, so it stops sending probes randomly when you turn it on. This is also the reason you dont always get all past SSIDs from a device, because some devices do not connect automatically or only at certain intervals (which you can miss).


Is it a safe to hardcode my secret key in my iOS app?

The API-SECRET as the name implies is secret and therefore should never be revealed in the client-side (nor on mobile applications).

This credential is being used for generating signatures which can then be used for listing, deleting, overwriting and editing your content.

You should either store it on the server side and pass only the generated signature, or use client-side unsigned methods which don't require signatures.


When exactly is Diffie-Hellman used in TLS?

DH is a key exchange algorithm, it is used to derive the session key that's later used in the symmetric encryption. DH by itself is not authenticated, so while you can derive the session key without a MITM being intercepted, there's no guarantee that the guy on the other end that you're deriving keys together with is whoever they say they are. Not being able to authenticate the other party means that you'd still be vulnerable to MITM anyway.

RSA is an asymmetric encryption algorithm. RSA can be used as a key exchange algorithm too (without DH), however the RSA key exchange algorithm lacks the property of Forward Secrecy. Forward Secrecy is the property that an attacker that recorded your encrypted communication and then later obtained your private key, they shouldn't be able to decrypt the previously recorded communication. However, RSA can be used for signing and authentication.

DH is used together with RSA so that you get a communication channel that are both authenticated and is forward secure.


No. If you only encrypt the system drive, the other disk units will not be protected. Many systems allow to boot from a removable media (CD/DVD or USB memory stick). It is the standard way to recover some data after a system disk failure.

But if an attacker manages to boot from such a removable media, all non encrypted disk will be unprotected.


webapp directories should have the directory name as owner and group?

I don't think the suggestion is particularly to have the same value as the user and group as the directory name, but rather to have a single user/group for each directory.

If you use www-data for all cases, then a compromise of a single site (or malicious site owner in the case of shared hosting) can easily read & write files into the other site directories.

Having multiple users (one per site, for example) mitigates the damage in a compromise.  Typically, you'd want www-data for the group (and group readable, but not writable permissions) so your webserver can read all of the static files, and to run a per-user instance of your application server.  (For example, one php-fcgi or python gunicorn instance running as each site owner, for the appropriate language.)

You can use adduser, but I would use both the --disabled-password and --disabled-login flags to ensure that the new user does not also become an attack vector!


Almost certainly (~98% confidence) it's a scam. 99.9% confidence if "pfax8fg0gq" isn't actually one of your passwords, but even if you have used that password, it's still more likely to be a message from somebody with access to the password database of the site you used it on trying to scare you, rather than truthfully having compromised your machine.
A handful of clues in no particular order:

Gmail recognizing it as malicious / junk
This is a very common scam format (which is why Gmail recognizes it), practically a form letter and the modern equivalent of the "Nigerian Prince" 419 scam. I've gotten it multiple times myself (with minor variation in wording), only occasionally with an actual password from my past, and never paid or gotten "embarrassed" by the consequences of not paying
Sender name and email address don't match
Awkward, poorly-written English indicative of the author not being fluent or at least not a native speaker
An actual blackmail attempt would have no reason not to provide evidence (such as a screenshot from the supposedly-captured video, and/or one of the harvested email addresses); the lack of any is strong evidence against it being legitimate.
The terminology is vague enough ("the adult videos website" rather than any specific site, "video you were viewing" without any details, "to have fun"/"it is u" without any specific reference to what you were doing that might depend on what body parts you have or how you watch porn, etc.) to be plausibly true for a large number of people when, again, an actual blackmailer could and usually would be more specific.


in you question concerning multiple inner hidden containers - you wrote

  nobody would ever know how many inner hidden containers you have,...

That would be unnecessary overkill because you may not know one-day either :). Could happen if you are really such a security minded person. And then what?

Say you already have an encrypted veracrypt volume/partition, etc. Adding a hidden volume requisite you create an outer volume in which to hide it. That means you must have several headers for  veracrypt to determine where each volume begins/ends;  no problem here since the wizard does the calculating for you but have your paper and pencil at hand. It becomes a juggling act remembering how big, where is what, which password to use, how many volumes did I create, etc..- when creating even multiple volumes in which you can create hidden volumes!!

Getting back to my scenario above... I would have two headers from which veracrypt can work with. It becomes even more complicated – in terms of security/secret – since each password muss be strong and unique! I can manage keeping 5 STRONG passwords/phrases in memory without writing them down but more than that requires physical notation because of their infrequent usage, and that becomes a security issue – where to store them. Albeit, the best passwords are the ones you can't remember - I am borderline!!

You didn’t mention how many inner volumes for each hidden veracrypt volume but more than one would set the stage for a chaotic scenario as mentioned - above. It would be like the concept of the Russian Matryoshka doll of nesting 7 in one. Adding the option of multi-inner hidden volumes (if at all practically possible) and you have utter chaos in the making!!

The challenge of already providing a user-friendly application and retaining the atrributes of confidentiality, integrity and availabilty would be totally thrown out of the window if such complexity was added to an already workable solution!!

Besides a hidden volume is a hidden volume without dressing veracrypt up like a Russian Matryoshka doll. Veracrypt allows that much TODAY and you have a better overview of what you may have just done.

And if you follow instructions carefully,  according to VeraCrypt,

  Even when the outer volume is mounted, it should be impossible to
  prove whether there is a hidden volume within it or not, your data should be well hidden.

That is my unprofessional thought on the matter.


Why does GPG insert dashes into signed messages?

GPG does that because OpenPGP standard (RFC 4880) requires it:

  Dash-escaped cleartext is the ordinary cleartext where every
  line starting with a dash '-' (0x2D) is prefixed by the sequence
  dash '-' (0x2D) and space ' ' (0x20). This prevents the
  parser from recognizing armor headers of the cleartext itself.
  An implementation MAY dash-escape any line, SHOULD
  dash-escape lines commencing "From" followed by a space,
  and MUST dash-escape any line commencing in a dash. The
  message digest is computed using the cleartext itself, not the
  dash-escaped form.


Check whether a printer keeps a history of printed documents

Best resource would be to ask the manufacturer. How much printers cache and how they secure it varies widely.

For Consumer grade hardware, there is unlikely to be a mechanism for securely wiping the contents provided, since consumers don't need such a feature, so probably you'd need to look at physical destruction.


How can I safely include the encryption key in the encrypted file?

If you have a good encryption algorithm, it shouldn't matter that you include the encryption key. However, better than storing the password itself you better store a salted hash. Or just a truncated version of it (the basis being that a user error is unlikely to mistype one of the very few colliding passwords, while a brute-force attack would not be able to use it for knowing for sure that it got the right password).

But we shall also take into account that we additionally want the file not to be modified. So we can just include a hash of the file and if it is there and matches what you decrypted, he knows the password. GCM as suggested by Stephen is also an alternative to including a hash.


Password strength with grouping of characters

If your password hashing function is any good, or even if it is bad but not hopelessly so, then adding the dots should not weaken the password. Password hashing functions, like other kinds of cryptographic hash functions, are supposed to be "all or nothing": either you have all the exact input, and then you hash to the output, or you learn nothing. The corresponding academic notion is that of a random oracle.

Of course, the extra dots do not increase the entropy of the password, while they may increase typing efforts. It is true that they increase readability, but whether it enhances or depreciates typability (mmh, that's not a word, apparently) depends on who is doing the typing.

Some poorly developed systems enforce arbitrary low limits to password length (e.g. they reject passwords longer than 10 characters) and the extra dots will make you hit that limit harder. Arguably, these systems are the problem, not the dots.


Are there firewalls we can use that have domain based rules, instead
  of IP based so our API requests continue to arrive un-interrupted yet
  we continue to block all other outbound connections?

Yes, although usually through a proxy functionality rather than a traditional firewall rule sense.

For example, the Check Point URL Filtering Software Blade allows you to restrict outgoing HTTP and HTTPS connections based on the DNS name they request access to - e.g., either a GET http://example.com/ HTTP/1.0 or a CONNECT example.com HTTP/1.1 would only succeed if a rule exists permitting access to example.com.

The proxy aspect is a result of the problem space.  Reverse DNS cannot be trusted in any way, shape, or form, so the firewall can't just reverse the IP the client wants to connect to and decide based on that.  It has to be handed a name by the client, and to make its decision based on that.  HTTP-style proxies work fine for this because, even when it's for an encrypted connection, the client hands the name over to the proxy before the connection can be made.

The problem with this approach is that it effectively bases security upon the result of DNS queries against remote domains.  Reverse DNS can never be trusted because anyone can put any name in for an IP they own.  But even forward DNS lacks the security required - you can safely assume that a moderately motivated attacker can manage to spoof or poison DNS if it allows them to exfiltrate PCI data from your datacenter.

(That does not mean you couldn't get this blessed by a QSA - it's a reasonable compensating control.  I just don't want you to think it's fully secure!)

I approached the same problem - for the same reasons as you - over a year ago, and concluded that the "secure" method would require that something more than DNS to vouch for remote sites, and that the SSL certificate was a reasonable thing to pin the security upon.  I ended up implementing such a proxy and using it for my purposes; the answer mr.spuratic provided promises to do the same thing (the only reason I haven't accepted it yet is because I feel the need to test it first).


Why is salt+nonce authentification over insecure channel vunrable to man-in-the-middle attack?

Active eavesdropper MIM::
With a MIM able to not only see, but also modify information exchanged between you and the server (eg: a proxy), I can intercept the first message and change the salt and nonce to zero values.

You will reply with a hash of your password with basically no extra data added to it. I can take this hash and look it up in a pre-computed table (lookup table or rainbow table) to see if I can find your password matching the hash.

Passive eavesdropper MIM:: Now, let's say I'm an observer only and cannot modify any data within your communication but still see it all.
Since I know your salt and nonce, I can attempt brute force or dictionary attacks on your password. This is probably more expensive but would still work in case your password is weak.

This should show you how important it is to exchange authentication information over a secure channel. The minimum requirement should be TLS with server certificate verification.

edit: server certificate verification includes certificate chain verification and server hostname verification (the host you're connecting to is the one listed in the server certificate). The latter is important to prevent MIM attacks.


Backing up SSL certificate private key files

You have basically three options:

Backup the key with the rest of your server, and makes sure that the backups are handled as confidential data. Some backup solutions can automatically encrypt backups, which can help in solving issues (but take care that encryption does not magically solve problems; it just reduces confidentiality of data to confidentiality of the decryption key).

In your case you do not make backups of your servers, so this option does not really apply to you.
Backup the private key alone. Since private keys don't change often, you don't need to do a weekly backup; indeed, you can do that backup "manually". A private key is sensitive data, so some sort of protection is strongly advised. A customary archive format for private keys is PKCS#12, also known as "PFX" (or ".pfx file"). This format can embed the key and the certificate and some extra certificates (e.g. intermediate CA), and supports password-based encryption.

You'd better make a strong protection password (say, 20 random letters). You won't type that password often, so you will forget it; therefore, write down a copy of the password on some piece of paper, to be kept in a sealed envelope in a safe. The PFX file itself can be stored just anywhere (well, don't put it on your Facebook account, because it would look a bit careless; but if you have a strong password, then this will provide enough protection).

Windows supports PFX archives natively. Note that Windows will not allow the creation of a PFX archive if the private key was tagged, upon generation, with the "non exportable" flag. On Linux systems, use openssl (the command-line tool).
Don't backup the key at all. If your server burns down and must be created anew, just obtain a new certificate for your CA. SSL certificates are for authentication and encryption of data in transit, so there is no permanent data loss if the private key becomes unavailable. Some CA won't even bill you for issuing new "replacement" certificates (the kind of CA who makes you pay per server name and per year, not per certificate). In any case, the cost of a new certificate will be dwarfed by the cost of new hardware and, even more importantly, by the salary of the sysadmin who will have to reinstall the OS, software and Web site.

This solution is the simplest of all, and can be cost effective as well. However, it may entail a longer delay before resumption of normal activities, so you will prefer to do that for multi-frontend servers, where a missing frontend is annoying but not crippling for business, and thus recovery can be delayed by a few hours.

If your server uses a Hardware Security Module, the none of the above applies (except the possible "no-backup" strategy); instead, the private key will be backed up with the HSM-specific procedure.


Process and order of verification of a X.509 certificate chain

I think you are conflating certificate path validation with certificate path building (RFC4158). Building is most often done from the end entity by fetching the AIA URI and should include elements of validation to help guide the path to the correct destination (i.e. trust anchor). Validation is then performed on the output of the path building which necessarily always includes the trust anchor.


There is always a trade off between the level of security and the amount of time and effort that you're willing to put into a project. For a personal blog I would reccomend you keep these things in mind.

Always update your CMS. No matter if you choose wordpress, drupal, django, or something else make sure that you always check for security updates. The very minute you publish something on the internet it will be scanned from around the world for weaknesses. Keeping up to date with the latest patches will keep you much safer.
Use a strong password! There are some good posts on this site regarding password management. Automated scanners will be brute forcing your admin page the second it is published. So use a unique password.
Use multi factor authentication, if possible. For the admin page of your site you can sometimes enable multi factor authentication. If the CMS that you choose offers that as an option, use it.
Keep backups. In the case that something goes wrong. Make backups as often as you are able to. (If you're making periodic posts, just back up the site after each post).

An alternate solution. You mentioned that your site will be "mainly just be static content with a section for readers' comments." If this is the case then you may want to look into static site generators. The idea is that you can generate a very nice site (especially a blog) offline. The site generator will spit out for you static html/css/js. You can then take these files and use a CDN (Amazon S3, for example) to host the site. Your web site will have a really hard time ever being hacked if it accepts no dynamic content! Comments can also be enabled on a site by offloading that work to another provider. Discus or Discourse may be viable solutions.


Does IMAP/POP3/ASP undermine Two-Factor Auth?

You are not missing anything.

It is a convenience option that usually has to be opted into specifically when 2FA is enabled - and somewhat defies 2FA.

Otherwise, smart phones and email clients would be quite useless, or at least cumbersome.

In the case of smart phone mail clients: for most 2FA options, the smart phone is the second factor, so there is no massive benefit from it either. (And other options might not be possible, for example iPhones cannot use yubikeys).

Nonetheless, 2FA still helps you when the IMAP/POP3/SMTP password is strong and unique for that account and the connection is secured by TLS: you can still not be phished and can use your smartphone and the password can not be brute forced and can not leak (because it is strong and only used there).


How can you trust that there is no backdoor in your hardware?

The short answer is, you can't. The longer answer: there are a few things that can be done to increase your trust in hardware, though they also just shift the root of trust elsewhere.
A first interesting question you pose is the software/hardware distinction. To not go into the discussion about the possibly blurred boundary between the two here, I'll understand "hardware" to be non-reconfigurable logic implemented in some physical device (i.e. I'll exclude firmware such as the intel ME or microcode).
Backdoors can be inserted into a physical device in a number of stages: from conceptual architecture, through logic design, up to fabrication. To ensure no backdoors are inserted, you would need to validate the whole process from the end product to the beginning.
The good news is that the initial stages are very similiar to software - in fact, logic is usually designed using hardware description languages (HDL). These designs can be audited in the same way software can be audited. The step from here to fabrication involves multiple conversions e.g. to lithography masks using synthesis software, in a similar way to how software is compiled using a compiler. These too can be audited just like a compiler. (As a tangent - the bootstrap problem is a really interesting problem where you consider the possibility of the compiler compiling your compiler being untrustworthy)
So this leaves the last step: fabrication. Validation at this stage is usually done both by inspecting the fabrication process, and by randomly sampling devices from the same production batch (produced using the same lithography masks). For instance, the masks used can be compared to a validated trustworthy copy to ensure that no backdoors are inserted at this stage. Similarly, randomly sampled devices can be delayered and inspected under an electron microscope.
However, as a consumer, these steps are usually not available to you. For most chip producers, this whole process involves a lot of closely kept trade secrets, and aren't publicly available. This is why there is a movement towards creating open-source hardware toolchains and HDL implementations of common logic modules and systems - though there are a number of problems here too.
Finally, as @knallfrosch correctly points out in the comments, backdoors may also be inserted after production, either at a distributor, while the product is being shipped to a customer, or in-place (c.f. evil maid attack). An example of such practices by the NSA has come to light through the Snowden affair. Tampering at this stage may range from hardware implants added to the device to editing the circuit on a silicon die e.g. using a Focused Ion Beam (FIB).
Mitigations at this stage usually rely on these kinds of tampering leaving externally visible traces, which may be additionally enforced using e.g. tamper-evident packaging (something every-day users can do is the glitter and nailpolish technique). Furthermore, minute device-specific imperfections that are a side product of fabrication may be used to create so-called Physically Unclonable Functions (PUFs) which may be designed in a way that tampering will most certainly alter or destroy the PUF and therefore be detectable.


How to deal with websites with poor encryption?

Part of the SSL Handshake is to determine the cipher to use during transmission.  The cipher suite order can be set server side.  Is RC4 the only algorithm being used?

You can disable the algorithm on the client side by editing the registry.

See this link.  MS published an update to disable RC4.  I also believe you can use a tool called iis crypto to edit your registry.

For firefox, it seems like you can control the SSL ciphers via the about:config page.  Look for security.ssl3


Is asking for credentials from a separate trusted domain an acceptable practice?

The flip side is that an XSS in a site gives you access to everything on the same origin.  So, if an attacker finds an XSS anywhere in example.com, they can use it to steal login credentials from example.com/login.  With a separate login domain and HttpOnly cookies, this is significantly mitigated.  (Of course, you need some way to pass credentials from the login domain to example.com, and implementing that without leaking the credentials to an XSS is non-trivial.)

Yes, it's probably bad form to teach users to login on a different domain.  Often using a subdomain provides a good balance of containment (via origin) and usability.  See, for example, accounts.google.com for a login page on a different origin, but recognizable domain.


is it possible to keep something invisible to the server admin?

No, as a rule of thumb you can't completely block administrators and still allow them sufficient access to do their jobs. You can throw up some barriers that make it difficult for an individual abuse their privileged access (and remain undetected) without conspiring with others.

Most companies deal with these kind of challenges in more or less the same way: they mitigate the risks with procedures and controls, enforced by contracts, technology and auditing.

you hire capable and trustworthy people and offer them sufficient incentive to continue to act in that fashion (the carrot: interesting work, appreciation, cash and the stick: penalty clauses, prosecution, etc)
after initial setup administrative access is restricted (think very limited sudo instead of a known root password)
use tooling so your administrators don't need actual access to the systems commandline to perform common administrator duties
privileged account management, every privilege escalation follows procedure and requires a strict four eyes principle
No single individual gets to hold all the keys to the kingdom
trust but verify, implement independent auditing
separation of duties, a sysadmin does not have DBA rights, nor vice versa
encryption of data at rest (makes it difficult to get to your critical data by by-passing internal access controls in your application by reading it directly from disk)
SELinux mandatory access controls can really restrict "the power of root"
and I could even imagine a setup where every administrator action is scripted, rather then manually executed.

So there is no single measure, but a combination of the measures I mentioned and many I may have skipped, can make it difficult for a sysadmin to get access to data he/she should not, at least not without discovery.


Should you remove the user's application PIN if they explicitly log out

So you have a setup where the user needs to do full username / password authentication, but as a short-cut you allow them to use a PIN until the session expires.

I would follow the model used by the Keepass2Android client:

When you open the app (equivalent to your new session), you need to do the full authentication process.

While the app remains open, but in the background, you can re-open it using a short-cut -- last 3 characters of your password, fingerprint scanner, etc (equivalent to your PIN, I think).

When you fully close the app, you will need to do the full login next time.

So following that model, I would have them enter one PIN at install, when opening a new session they must re-enter their full credentials, and while the session is open they may use the PIN.

I don't see any difference here between whether the session expired naturally or because they clicked Log Out. I also don't see any reason to ever force them to choose a new PIN; that seems like it's asking for usability problems ("What's my PIN again??") for minor-at-best security benefits.


Give only execute permissions to a Linux binary (prevent inspection)?

This is a partial answer as I've got little time...

Your approach would prevent plain reading of the file but students could still cheat, e.g. by LD_PRELOADing, and changing any of your internal functions to literally print the stack/heap on screen. You must prevent changes to the environment as well (you can unset LD_PRELOAD as a first thing in your main()).

Students could also strace your program, and that might or might not reveal internal strings depending on the system calls you make with them. However, according to Gilles' comment on this question, strace will not honour suid/sgid bits when executing.

To prevent both gdb/ptrace attaching and strace, you can make the program suid/sgid to a specific identity that has access to a file chmoded to 400. This will mean that the executable must be run with that suid identity to access the secret. In fact, if I remember well, LD_PRELOAD should also be ignored by suid binaries.

You can easily verify this by building a program that prints the results of geteuid() and getuid() and run it, chowned to root and with the setuid bit, both normally and with strace.


Redirection - Different Website from Different Computer

There are various ways of redirecting the requestor to the site you want. Your idea is a good option because you are able to focus people from different countries depending on the focus of an attack. If it needs to be a bit easier you can check the User Agent, OS, Language and other variables that will be sent by a browser. If you want to focus a Windows PC you check the agent and redirect to the malicious site. If an iPhone is surfing to the same site there could be another reaction depending on the attackers needs. This method generates not that much overhead as it doesn’t need to involve other servers to check the origin of the IP address.

If I wanted to analyze the malicious website, I would frequently have to log in to one of my AWS virtual machines (each having different Public IP) and then visit the URL. Is there a better way of doing this?

If you want to analyze a Webpage on their behavior it depends on the language of the Page (PHP,JS,…) If it is written in JS it’s easy because you can request the page and look into the source code. If the redirecting function is server side implemented you have to try all User Agents, different IPs and mixtures to get the full information what combination redirects you to which page.


what order does the incremental mode of john the ripper, brute force passwords in?

Incremental mode is not meant to be used with a wordlist. Incremental mode allows you to bruteforce a character space such as lowercase letters. For the example of the lowercase character space the bruteforce would start at one character, try all the combinations, move to two characters, and repeat until the password is cracked.


Can you forward TLS connections according to SNI domain without terminating the connection at the reverse proxy?

It is possible to do forwarding inside some proxy just based on the SNI extension in the ClientHello and without terminating SSL at the proxy. It is for example supported by haproxy or sniproxy. See also Can a Reverse Proxy use SNI with SSL pass through?.


Can any private key information be exposed when signing an email?

Short answer: no.

Longer answer: If your PGP encryption is vulnerable to known-plaintext attacks, then that means PGP is using an old broken cipher. Modern, non-broken crypto (with updated software) will not have vulnerabilities like this. You can encrypt or sign whatever you want and no secret key information will be revealed.


What is the importance of an ISP maintaining IP-Assignment logs?

It's certainly possible to do it that way, and indeed investigators will sometimes ask many different parties for information related to a case to piece together scattered evidence, but why would you want to obtain this information from Google when it is much easier and more reliable to obtain it directly from the source (the ISP)? After all, the ISP is the entity that actually assigns IP addresses to its customers, so they're going to be the ones with the most accurate information about who has what IP address at what time. The ISP also has an incentive to identify and remove malicious users from their networks. Asking Google can be hit-or-miss; for example, what if the malicious user's IP address changes right after signing into Gmail but before he performs the illegal activity? Or, more likely, what if he never signs into Gmail or any other service at all around the time of the incident?

Also, think about it from Google's perspective. If the illegal activity neither targeted Google, nor was it performed from Google's network, why should they be willing to get dragged into this and be forced to spend the time and resources necessary to locate the information when the ISP could provide it much more easily? The only relationship Google has with anything is that the person who did it might have an account with them and might have logged in around the time of the incident.

While a court could force them to provide some information about the IP address in many jurisdictions, they're certainly not going to be very happy about it or eager to do it unless it's an extremely serious case and you have evidence that the person is a Google account holder. It's also bad for PR, as tech companies are increasingly trying to demonstrate that they respect privacy after the Snowden leaks. They publish the number of government data requests they receive, and if this number is high, the news media will pick it up and it's bad for business. If you found out that Google is the first source of information authorities turn to in investigations and Google happily hands over anything they ask for, would you still be willing to trust them with your personal data? I certainly wouldn't.


The client just connects to you. The Pineapple simulates an open wifi network, it can't simulate a password protected network. To get the password the Pineapple would require information to complete the handshake which is unknown to the device.


Does an open port with no service listening on it pose a risk?

In nmap terminology, an "open" port is usually the port where a service is bound on, and listening; otherwise the port is not open.

However, it seems like you are asking about having a port open on firewall. This is, allowing the remote hosts to connect to port 9991 on a server through firewall, even if there is nothing bound on this port and those connection attempts result in refusal. Yet this poses a few risks:

If your server is compromised, one can run an HTTP server on that port, and use it to spread illegal content (such as ransomware binaries, or host C&C server).

More, in the enterprise setup, this compromised server could also be used to infect other machines inside the organization - including those which couldn't connect to Internet - via phishing attacks pointing to this server. This would have a higher chance of success as corporate users might trust internal servers more than external servers.

Finally, making the compromised server easily accessible is much easier when one can simply launch sshd listening on this port.
If someone upgrades the OS on this server, a new version might introduce a service listening on this port. This service might not be secure in the default configuration - for example it might have known default credentials - and result in exploitable vulnerability.


Is sending email between different Office 365 domains (and organisations) secure?

As luck would have it, Microsoft has documented this. The answer to your question is yes. They use TLS 1.2 between any Office 365 groups, and they also use it opportunistically for external destinations, so as long as the recipient's server supports it, that message path will also be encrypted.

https://technet.microsoft.com/en-us/library/mt163898.aspx

and not to humblebrag or criticize, but to find this I literally googled "does office365 use tls to send email"


Why firefox shows some connections are not secure?

The date/time on your device maybe invalid.

All SSL certificates have a start and end period.  Certificates can be compromised and its a good practice to renew them.


How can you spoof a TCP connection to a device that uses the same initial sequence number for each run of a TCP handshake?

"Spoofing" is normally about using a fake source address. You want to connect to the target, without revealing your actual IP address, instead using another IP address. In your case, you (the attacker) perfectly know the device's IP address; what you do not want to reveal is your own IP address. You want to open a connection with the device such that the device believes that it talks to a client with a completely distinct IP address.

The main problem with spoofing is that while you can send arbitrary packets with a fake source IP address, you won't receive any response, because responses will be sent to the fake address, not yours. This, in particular, makes it very difficult to complete the TCP handshake because each party must send s+1 as an acknowledgement of the sequence number s sent by the peer. If you are the client and are trying to spoof, you won't receive the SYN+ACK packet from the server, and thus won't know what value to put in your own ACK. You might "get lucky" but since these are 32-bit integers, the probability of success is only 1 in 4294967296.

Now, if the target server uses a poor random generator, then your probability of guessing the sequence number chosen by the target may go up. In particular, if the target server always uses the same value (a very poor generator indeed), then you can guess it with probability 1, i.e. succeed each time. You can thus send a SYN, not receive the SYN+ACK (because it is sent at the fake address), but still send your ACK with the right value, based on your "guess" of the sequence number chosen by the server. The server will be content with that ACK. At that point, you can send arbitrary data through the connection. Of course you still won't see any answer, but if the point is to issue commands, then this is sufficient (example situation: you want to send spam through a SMTP server that refuses email sending except from a few specific client IP addresses).

In all of this, all your packets must bear the fake (spoofed) IP address.


Which method is the best for IDS : heuristic or signature based?

So in overall,which one should I prefer ?

You should prefer the one where you are able to deal with the logs and how much security you need and how much time you can invest to deal with false positives.

Static signatures will fail to catch new attacks but have usually less false positives. Heuristics might catch more new malware but this usually comes with higher false positive rate. You need to look through the logs and decide yourself if this a true positive (i.e. attack) or not. If you are not able to do this then the heuristics will probably be only in the way when accessing harmless sites.

Apart from that heuristics are usually not used alone because they might be able to detect an attack which has no signature but fails to detect attacks which have a signature. Thus they are usually used together with the static signatures.


Is HTTPS still secured with a known server certificate (private key)?

To get terminology straight: the certificate is the public part. It is public so everybody knows it, and when a client connect to a SSL server, that certificate is one of the first things that the server sends to the client. What you mean is: when the private key is not really private, can SSL still be considered as "secure" ?

The answer is basically: No.

However, there are subtle details. When client and server talk to each other, they agree on a set of cryptographic algorithms to use, called the cipher suite. See the standard for (most of) the currently defined cipher suites. One of the elements of the cipher suite is the key agreement method used to exchange the "pre-master secret" from which all other keys are derived. When the cipher suite is a basic "RSA" suite (i.e. the cipher suite names begins with "TLS_RSA"), then the key agreement is basic asymmetric encryption with RSA: the client generates a random pre-master secret, encrypts it with the server's public key (from its certificate), and the server decrypts it to recover the pre-master secret.

When the server's private key is known to an attacker who merely eavesdrop on the channel, then that attacker can also decrypt the message from the client, obtain the pre-master secret, and decrypt all the data. It seems safe to say that, under these conditions, there is very little security left.

However, if the negotiated cipher suite is of type "ephemeral Diffie-Hellman" (the name begins with "TLS_DHE"), then the actual key agreement uses Diffie-Hellman with public/private DH key pairs which have been randomly generated on the spot. The server's private key (the one which is hardcoded and thus not very private at all) is used only to sign the DH public key. Under these conditions, a purely passive attacker, who merely spies on the data packets but does not interfere, will not be able to get the pre-master secret, and the connection will remain secure. This feature of DHE is called Perfect Forward Secrecy.

However, even with DHE, an active attacker can impersonate the server and mount a Man-in-the-Middle attack, voiding any security. PFS is an actual advantage only when considering the case of a private key ulterior theft, where the attacker steals the server's private key after the connection has occurred. At that time, it is too late for the attacker to be "active", and PFS locks him out. But this is not your situation: you envision a case where the attacker already knows the server's private key when the connection happens. The attacker can then mount an active attack.

So, to sum up: when the server's private key is known to attackers, then security is maintained only against passive-only attackers, and then only if the client and server agree on a DHE cipher suite.

(Strictly speaking, security can be salvaged even against active attackers if the cipher suite is DHE and the server requires a client certificate and the client private key is not known to the attacker. That's an edge case.)


TCP off-path attack: which ends need to be vulnerable?

The attack is using a specific implementation of RFC 5961 on the server as an oracle to find out which connection (ports) from a specific client exist and what are the current sequence numbers. This means it is enough that the problematic implementation exists on the server.


ASLR does not seem to randomize text section

The text segment is not typically randomized in ASLR implementations, and this is why Return-Oriented Programming (ROP) chains work.   The idea is that the application's own code should be 'safe',  so randomizing this memory space would be a waste of resources.

ROP chains are about building a malicious payload using the application's own functionality.  A good analogy is that you can take any well meaning sentence,  and make it an insult by choosing specific letters or words to make a new meaning.