Found 0000 Permission Files on a hacked server

If your server has been compromised, then assume they have root access. Even if it appears that you removed offending shell scripts (which a lot of times is all the "clean up" entails), it's entirely possible for them to dig deeper into the system. You have no idea what exploits exist for the server software, so it's entirely possible that uploading a simple php shell script could lead into a complete compromise of the OS or worse.

You are correct that 000 permissions would only allow a superuser (root is, by default, a superuser) to make changes to that file. However do note that a non-superuser could delete the file and upload their own copy in its place as long as they have write+execute permissions to the directory containing it.

As to why they might do this, it really depends on context of the file in question. Largely, it could be broken down into two categories:

The file is meant to be blocked and left alone.

This would likely be to cause a Denial-of-Service to whatever depends on that file.
This could also be an attempt to quarantine the file, without necessarily deleting it. Then, the superuser could safely open the file (read) to investigate it, send it to another service for analyses, etc...

The file is meant to be blocked for now.

With superuser rights, the attacker could later change permissions to execute the file.
Without superuser rights, the attacker could later delete the file and replace it with their own.

Realistically speaking, I have doubts they would re-hack you in the same obvious ways if they had deeper penetration of your server. On the flip-side, we have no idea what kind of concoction of exploits they have available to them on the second go-around, or in the future while they still have access. Therefore it is safer to assume the worst-case scenario until proven otherwise.

While we can make guesses as to why we're seeing this specific behavior, I don't feel it worth your time to personally investigate it. Contact your hosting provider, let them know what happened (aka what you described to us here), and let them investigate it. They could have additional logging/auditing available to them, and if all else fails, they could take the standard LOIC approach to compromised systems.


Are digital signature algorithms subject to the same types of attack as public-key encryption algorithms?

Does using a public-key encryption algorithm in a digital signature scheme enable any additional types of attack?

Yes.  Using PKE for a digital signature has additional attacks; e.g., if you are using an RSA signature there are collision attacks on the hash function where if you can construct two messages m and m' that both have the same hash (H(m) = H(m')), if you can legitimately get someone to sign message m, then you can append that signature to message m' (even if you could not legitimately get someone to sign message m').

For example, back in the day MD5 was used as a hash in SSL certificates (X.509 certificates).  However, it is possible to carefully construct MD5 collisions in much less than the expected 2^64 work.  Therefore, an attacker merely had to construct a collision between a valid certificate they created (for say a website they control) and an intermediate certificate authority (note they should not alter the modulus or exponent to construct the collision as they need the private key).  Then when you can get a trusted certificate authority to sign your valid certificate for the website, you can append that signature on to your fake intermediate certificate authority.  Voila!  You now have a trusted intermediate certificate authority and can sign any certificate you want and get web browsers to trust it.

This attack was successfully done in 2008.


Is it possible for corporation to intercept and decrypt SSL/TLS traffic?

Installing a root certificate on users browsers, and conducting a MiTM attack on employees is unfortunately a standard practice at many companies.

There's a few ways you can detect this.

One way is looking for a root CA cert installed on your computer and see if you don't recognize one of the CAs.  This of course requires an in-depth knowledge of what real root CAs are, and what fake MitM proxy providers are.
Another is simply looking at the certificate an https websites
generates and examine who it's signed by.  The cert of all https sites will
be signed by the company providing the MiTM attack proxy.
A third way is to install Firefox, preferably a version that doesn't
install and runs as a standalone.  Firefox doesn't use the system
provided certs, but uses its own certs.  You can get this from
http://portableapps.com/  If you then get a security warning about a
self signed certificate, you're being MiTMed by your company.


How to deal with responsible disclosure "catch and kill"

You should report the vulnerability to Mitre to get a CVE assigned, or on Full Disclosure.

When a vendor refuses to fix a bug that you've reported, it's ethically acceptable to disclose it openly or try to get a CVE assigned for it. This is especially important if you believe that the bug may be being exploited in the wild, and even more so if knowledge of the vulnerability allows easy mitigation by end users. People typically wait a fixed period of time before reporting a vulnerability that has not been fixed. It's common to disclose the issue to the vendor and wait 90 days before making it public.

They will probably kick you out of the program, but they cannot get the money back without engaging in a messy lawsuit. In fact, because such companies are unable to easily take the money back without resorting to legal action, these 0day-selling companies (often the more unethical ones which pay the higher prices) will often give you the payout slowly over a period of time, allowing them to terminate payment early if you disclose the bug without involving the legal system to remedy violations.

It is very important to remember that, while the money is yours (assuming the contract says so!), you could be sued for breach of contract and forced to pay even more money than you earned (both in legal costs and in damages from the lawsuit). While breach of contract is not criminal in most countries, civil law is still in effect. If this is important to you or if you do not want to risk a lawsuit from a litigious company, you should consult a real lawyer and not take legal advice from strangers on the internet.


What are the security implications of enabling UPnP in my home router?

Many modern home routers usually come with a feature called Universal Plug and Play (UPnP) to allow NAT traversal using the IGD Protocol. What that means is that an application can ask the router "Hey, could you please let external computers speak to me on port xxxx", then the router creates a port map for the requested port.

UPnP has a variety of security problems, the main of which is that it doesn't have any built-in authentication. One example is PoC by Petko D. Petkov where he demonstrated how Flash can be used to send UPnP commands to a local router when visiting a malicious page. UPnP also makes it much easier for malware on your computer to open ports and listen for commands from a C&C Sever.

Despite not being around for a long time, UPnP has a long list of security issues mainly due to poor implementation. Researchers at Rapid7 have shown that nearly 81-million IP addresses have responded to their UPnP requests (mind you, those requests are coming from external networks), and many of these devices had vulnerabilities that can lead to complete takeover.

So my advice is this: If you want port-forwarding, you probably want it for a reason for a specific program, so disable UPnP and map the ports yourself. It's not something you'll be doing everyday.


Mathematically, how long would it take to crack a bcrypt password hash?

Ok, so from the article you linked, we learn that the 8x Nvidia setup can calculate about 100 000 bcrypt hashes per second (H/s). The cost factor used for the bench mark is 5 - very low - if the comments are to be believed. For bcrypt, the number of rounds equals two to the power of the cost factor. So if yours is 12, your hash will be 212/25 = 27 = 128 times slower. So from 105 H/s you're down to 103 H/s.

Now all you need to know is that to crack a hash with n bits of entropy, on average you need to try 2n-1 times. So take a password consisting of 8 random lower case letters for instance. It has an entropy of n = log2(268) = 38 bits. To crack it you would need 238-1/1000 seconds = 4 years.

Note that the benchmark is from 2016. As time passes by, hardware gets faster. You will need to regularly reevaluate your cost factor to stay up to date.


Host based firewalls aren't necessary if you have a dedicated network firewall.

However, defence in depth is always a good thing to practice. Host based firewalls allows you a more fine grained control on a machine to machine basis as well as allowing you to filter traffic coming from internal networks. This can be a great asset in preventing a single compromised machine on your network from compromising the rest of your network.


How to ensure privacy on a remotely hosted server?

If you cannot guarantee you are the only one who has access to the server itself you cannot ensure privacy to your users.

Wrapping an assembly is not necessary if someone who has access to the server wants to steal plain text credentials. They already have access to the server and thus access to the private key of the certificate. They could create a "legitimate" (to the end user at least) reverse proxy where they will terminate SSL and inspect plain text traffic. Using asymmetric encryption will not help either. Access to the server will grant access to the private key too.

One thing to consider if you have web hosting platform you can't (or don't want to) trust is to use client side encryption. But you can't do it in browser (JavaScript). Please see this for detailed explanation of problems related to browser encryption. In a nutshell, you can't trust JavaScript code that is served from a non trusted web host.

One possible solution is to use browser extensions. You can sign the extension with your own code signing certificate and thus users can verify the code came from you and it is not tampered with.


Does the use of plugin-id make the nessus scan intrusive in some way?

Nessus isn't a tcp scanner. Nmap is a scanner which finds open ports, Nessus is a vulnerability assessment tool which first uses a scanner to find open tcp and udp ports then then performs tests on the services found. Some of the tests it can do are intrusive and should only be chosen by looking at the risks.


Tokenization just uses random number generators to generate a certain ID and link that ID to a card, there is no way you can for instance reverse engineer the token from a card number or vice versa.

Sometimes the last 4 digits are kept as part of the token to display to the user. This is useful for certains shops, like Amazon, where a user might have configured several credit cards.

Normally tokenization happens in such a way that the randomness and keyspace are so large that colliding tokens are very unlinkely. In case a token would already be present it just needs to re-generate the random number prior to commiting into the database (often databases have unique constraints on the token as well as they're used as secondary or primary keys).

The pros are that you can reduce your PCI scope significanty. For instance databases used for analytics on a person's spend needn't be part of the  PCI zone as no PAN data will be present.

There are no cons. Some con you might have is for card acquirers that do not want their helpdesk to have access to their clients card numbers. So it might be that the acquirer needs to print an additional identification number on the card of the customer so he can be identified.


The teacher logged me in as administrator for doing a short task, is the whole system now compromised?

Was the teacher right to do this?

Yes and no. One might be tempted to say that giving a student administrative rights is highly problematic, and leaving them unattended even more so. And to some degree, I even agree with it. You may have added a new administrative user, changed the admin credentials, installed a rootkit or more.

But...

Acting maliciously would not have been without consequence to you. It's very likely that the teacher recalls giving you specifically administrative rights, and at what time. If in this very specific time window, something were to happen to that computer, the school can easily identify you as the malicious actor.

What consequences could there be? That depends entirely on what you did. Changing the local admin credentials could be considered a mere prank, and could probably be reversed by the domain admin. The damage would not be too high, but you could face detention.

If you were, for instance, to install a rootkit, then the school could claim you acted maliciously, with an intent to circumvent their security and to damage their systems. Arguing against that, when you installed what is essentially malware on their system, is going to be very difficult. It could be considered willful damaging of school property, and you could be expelled from school.

If you were to act even more destructive, by running malware designed to damage the hardware (e.g. hypothetically by overclocking the CPU to 12 GHz and disabling any self-preserving safety measures), then the school may even sue you for damages, in addition to expelling you.

Doesn't this imply that the teacher is at fault for providing me admin rights?

No. The teacher gave you administrative authorization to perform a very specific task. That does not give you the right to perform any task, even if you technically had the capability to do so.

If my friend were to give me the key to his house to watch over his dog, this does not authorize me to take anything from his house, or to install cameras everywhere - even if I was technically capable of doing so.

Can this not be considered a penetration test?

  "I was just testing the security of my school's computer systems."

No, it's not a penetration test. A penetration test requires the entity, who owns the system, to explicitly consent to the penetration test. A teacher providing you with administrative access to fulfill a specific task is not explicit consent for a penetration test.

What could the teacher have done differently?

Depending on the length of the task you were supposed to carry out, the teacher could have stayed with you and revoked your administrative access after you were done.

Given what was stated above, the teacher had a reasonable expectation that you would not act maliciously, which seems to have been misplaced.


PCI Scanning and authenticated user pages

Have you tried looking more into the options that may be available in the tool?  Personally, I tend to favor Acunetix, which does allow the creation of a login script so that it can scan as both an authenticated and non-authenticated user.  The only downside to this is that you are only able to setup a single login script for each individually run scan, whereas, some applications will have multiple seperate authenticated area's.


How to secure a website against a ping of death attack?

Ping of Death attacks are things of the past. Operating systems no longer freak out when assembling large fragmented ICMP packets.

That video is trying to demonstrate a ping flooding attack, a DoS attack in which he's trying to send more ICMP packets than what the server can handle. Chances are that the server being "attacked" has bigger downlink that the attacker's uplink. Allow me to demonstrate.

The guy in the video is trying to do something like this:

As you can see, he'll never be able to flood the server's downlink/resources. For this attack to be successful you need something called a Distributed Denial of Service attack (DDoS), in which a large number of attackers try to flood the server's resources

To learn about mitigating DDoS attacks, you can start by checking this question about different techniques used by firewalls.


Concept for (almost) untraceable networking setup

Using 3 AV programs at the same time is not advised. Using 2 is one too much. They will step on each other toes all the time, and maybe they won't work at all. Choose one good AV and stick to it.

Using Tor is enough. If you live on a country where using Tor is not a crime, you don't need a VPS, a VPN and a SOCKS proxy on top of that. Just Tor is enough, as your connection is not the weak link on your setup.

As others already said, you must mind your OpSec. That is the weakest link on your security, and that's the component that brings down most setups, not only on personal security, but enterprise security too. Logging into anything that could be linked to you while connected on Tor creates bits of information that can be put together and get to you. Logging on any restricted site while not on Tor can do it too.


What's the danger of having some random, out of my control, JavaScript code running on my pages?

Risk

In the worst scenario, it could render website completely inaccessible for the users, it could perform particular actions as them (for example, requesting account removal, spending money) or it could steal confidential data.

Prevention

Can't be done. If you run someone else's JavaScript on your website, it becomes no more secure than that third-party. You have to host it yourself.

You can get closer to the target, however.

One thing may be Content Security Policy. The example setting of header Content-Security-Policy to script-src 'self' www.google-analytics.com;, would prevent execution of scripts served from other domains than your own or www.google-analytics.com. That way if someone would find some cross-site scripting vulnerability (XSS) that would allow them to add their own inline JavaScript code to your website - it would not run.
Other really cool thing is so called Subresource Integrity. It's essentially adding hash sum of JS you expect to run to the integrity parameter you give to the script tag.

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"/>

You can generate those hashes online at https://www.srihash.org/ or with command:

openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A

This of course has downsides, e.g. analytics providers may change their scripts and you will have to change integrity parameter to keep them running. It's also pretty new feature (Chrome 45.0+, Firefox 43+, Opera 32+, no IE, Edge or Safari support at the moment), so you lay your client's security on their own software.

See also 3rd Party Javascript Management Cheat Sheet from OWASP.


If the Charles SSL Proxy shows me sensitive data, is that data insecure/exposed?

You seem to fundamentally misunderstand what TLS does.

TLS takes the regular plain HTTP traffic and encrypts it and adds integrity checks. Together with the certificate of the server, this ensures

Confidentiality: An attacker who captures the network traffic can not read the content of the communication.
Integrity: If an attacker modifies the network traffic, this would result in errors.
Authenticity: You can be sure that your communication partner is the server you think you communicate with. (We get to this in a second.)

If you were to look at the underlying HTTP communication, you would see your username and password in plain text, because this is what you have sent to the server.

What does the proxy do now?

If you use a TLS Proxy such as Charles, you essentially communicate with the proxy and the proxy communicates with the web server. So what stops an attacker from just using a TLS proxy? The certificate!

When you installed the TLS Proxy, the proxy generated a new CA-certificate, which you then imported. This means you gave the proxy the authority to create a certificate for any domain. For the purpose of being a proxy, this is fine.

An attacker however would have to make you import their certificate (or steal the private key of yours!) so you would trust certificates by their proxy.

So, is this an issue now?

No, it's not. Everything is working as it's supposed to.
At the end of the day, when you send your username and password to a website, it somehow has to actually reach that website.


To do this you will have to spoof the IP address of the DNS server and if you must pass through the internet, the attack will probably won't work for two reasons:

If the DNS server of the victim is in his intranet with a private IP number you won't be able to send the packet through the internet since private IP addresses from private ranges are not rooted over the internet.
If you spoof a public IP address and you try to send it, your ISP will probably not root it and it will just drop the packet. Before rooting a packet some rooters check if it is plausible that the source IP came from a specific interface.

If you don't need to pass through the internet to reach the external network, your private router may root the packets depending of its configuration


Certifications that involve practical knowledge

I think one of the most hands on security certifications out there is Offensive Security Certified Professional/Expert. The exam involves executing a penetration test and delivering a report on which you will get quoted. Now this certificate is aimed at attack and penetration testers, if your job is to administer Cisco equipment you should look into CCNAS or CCNPS.

There is also SANS but to be honest they are a bit expensive. The trainings are good though.


Is there a way to check the authenticity of a forwarded email?

For almost all mails one can not check if this is the original mail which was forwarded.

This can only be mostly done if the mail was cryptographically signed by using PGP or S/MIME and if this signature can be validated by the recipient. Even then this is not a full prove since the signature usually only includes the content of the mail and not the mail header.

One might also attempt to verify a DKIM signature contained in the forwarded mail. But, this is only proof that the mail was transported by a specific mail server and not that it was send by a specific user. Also it is not unlikely that the mail get invisible changed when forwarding it and thus the DKIM signature will no longer match.


The hostnames hr.company.com and testing-apps.hr.company.com will not cause proper browser security model segregation - it is possible for hr.company.com to set cookies than can be read by testing-apps.hr.company.com and testing-apps.hr.company.com will be able to set cookies on the hr.company.com domain. So you have to trust both hr.company.com and testing-apps.hr.company.com in order to use either, so it could be argued that LastPass accidentally completing the password details on one application is not that big of a flaw - the testing environment should be on a completely separate domain to prevent any vulnerabilities found from exposing the live domain. Additionally, passwords should never be stored in log files so while it could be considered a small bug (maybe it should prompt before filling a form on a different subdomain), it is not a huge security weakness in itself - the underlying web application needs to be trusted, which includes considering the browser security model. It could be that testing-apps.hr.company.com is only available internally. however this could allow a local attacker to compromise another employee's live account using a flaw on the test version.

In this case you can make this particular password manager more secure by configuration. e.g. disabling auto fill, and there is also an option in settings called URL Rules. Here you can set whether the hostname has to be an exact match. You cannot stop people using software in an insecure fashion, you can only guide and educate them, as you have pointed out.

  My question is this: These can't be the only examples of unsafe use of password managers. What other gotchas are out there? Can anyone recommend guidelines for safe use of password managers in an organization?

There will be flaws in all applications, whether at enterprise level or not. The advantage of browser based password managers is that is can protect against phishing attacks. The URL is validated and as default only the credentials saved for that URL will be completed. If this is something you want to protect against then you will pretty much need to use a browser based password manager. If using something browser based is too much of a risk then you can use a separate application, but you must accept that an unwitting user may accidentally log into a wrong website, whether a malicious one or not, potentially exposing their login credentials to a 3rd party.

The specific guidelines will differ depending on the software used and how passwords are used within the organisation, as well as the organisation itself. For example. does the organisation trust the cloud, or is everything done in house? Storing password data on trusted internal servers might be better, however the organisation is then taking on the extra work of making sure the infrastructure is properly secured and ensuring that the data is properly encrypted and encryption keys are securely stored.


What is Net-Worm.PHP.Mongiko trying to do?

This virus alert is a scam. The goal is to get admins to download and execute special "removal tools", which are in fact the actual virus.

Another note about how websites work and what you see in the access log:
You can go to basically every website and append arbitrary parameters like ?cmd=foo&key=bar and the website will just load and ignore the parameter. This suspicious log entry may not mean anything at all!

Monitor your system closely to see if your it is indeed doing something fishy. E.g., by logging all HTTP traffic containing suspicious parameters.

The removal tool as advertised (There's a link in the comments - do not install), will open your firewall and allow an attacker to remote control your machine.

I recommend you also watch the thread following this freebsd-security mailing list post, if you want to know more.


Your question is a bit vague, but I'll give it a shot. Public WiFi networks are known to be dangerous spots from which to access any private account on any web service. There are a few common attacks, like man-in-the-middle attacks in which an attacker intercepts unencrypted (http) connects and can take data, or dns redirects, in which an attacker either hacks the router and changes the dns to redirect to his malicious page, or spoofs the router and makes you connect directly to him. There are also extensions for browsers like firesheep for firefox which works by intercepting unencrypted cookies for popular websites and thus faking credentials to hijack a user's session.

Still, if you're accessing webpages via https and they have valid security certificates, you can mitigate some if not most of these threats. And in 2016, https is pretty widespread.

As far as using them to steal login info, there are more effective ways to get login passwords, especially if you have physical access to a victim's computer. As far as Google or Facebook, you can pretty much assume that their encryption algorithms are up to snuff (aside from NSA backdoors). The issue almost always lies with the end user or the way with which the user communicates with otherwise secure services.

And as far as physical access goes, there's always Lan Turtles https://lanturtle.com/ and Wif Pineapples https://www.wifipineapple.com/
Point is, you can't trust the infrastructure you use to access the internet, so every bit of info you send is encrypted between you and the sites you want to access, or at least that's the idea. You never know when you have government agencies like the NSA wiretapping the entire backbone of the internet for unencrypted data.

To my knowledge, it is not possible/practical for an attacker that intercepts encrypted data to decrypt it. However, this alone does not make your computer or online activity safe over public wifi. An outdated/unpatched operating system or browser security hole could let an attacker into your system, where they could do all sorts of nefarious things like install keyloggers, getting your information in other ways.


OpenSSL: How to set default_crl_days to infinite / never expiring?

The nextUpdate field (i.e. what you treat as expiration date) is a timestamp. There is no way to specify an infinite time but you can specify a time far far away. But note that if you set nextUpdate too far in the future you have to somehow guarantee that anybody checking the CRL is still using the latest one and not some old (but still valid) version which does not contain critical revocations.


You're better off not rolling your own on this. People that are good at it have been building such features into frameworks and libraries. Here are two that cover that and more:

OWASP Enterprise Security API
https://www.owasp.org/index.php/ESAPI#tab=Home

HDIV
http://www.hdiv.org/

OWASP also offers a wealth of knowledge on web security in general. You can also google for their section on handling passwords if you intend to roll your own anyway. They'll tell you the good and bad from registration to storage to recovery.


Looking at the code (https://github.com/RandomStorm/DVWA/blob/master/vulnerabilities/exec/source/high.php) it is definately vulnerable. You just need to take a look at what trim does and what characters are both whitespace and have special meaning on the command line.

https://github.com/RandomStorm/DVWA/issues/78


Did information technology had a increase or decrease in security with the introduction of automatic update features?

Auto-updates greatly improved security by fixing any non zero-day vulnerabilities.

Most vulnerabilities only become known to the general public after a patch for it is released. Years ago, when auto-updates were not the norm, black-hat hackers used to reverse-engineer any security updates, found out what vulnerabilities they fixed, wrote exploits for it and distributed them to target users which didn't bother to install the update. That gave us epidemics like Win32.Sasser which propagated through a vulnerability which was already patched when the worm appeared, but many people didn't have the patch installed.

But nowadays, the release of a security update means that in a few hours nobody will be vulnerable anymore. That's simply not enough time to create an exploit and distribute it.

The high patch frequency also means that people who look for zero-day vulnerabilities (which means: finding vulnerabilities on your own before the developers do) are aiming for a moving target. A vulnerability might get fixed even while they are still working at their exploit (sometimes even unintentionally).


There is at least a quite good collection of spam mails as such available at http://artinvoice.hu/spams/. I would consider phishing mails as a a subcategory of spam and expect you to also find phishing mails in that body.


Can an Android malware install a SSL/TLS certificate into non-root devices?

Any app can create a new KeyStore and do arbitrary things with it. So it is possible for a malware to import a downloaded root CA and use it for TLS connections originating from the malware itself.

This does, however, not impact any other app, as global KeyStores are not affected. To change it using official APIs, one needs to create an install intent via createInstallIntent, which can then be used to bring the certificate installation dialog up. Unless the user confirms the dialog, the certificate will not be installed.

Note that this answer does not consider exploits or other means outside of regular APIs to gain write access to global KeyStores, as your question explicitly asks for standard API only. An app with root access can of course use other means to change the list of root CAs.


nmap scan explanation for open port & services

In my experience, you have to treat the SERVICE and VERSION fields of those reports with a large grain of salt. Often the tool is just looking up the port number in a table; indeed port 23 is listed as the default TELNET port (see wikipedia/List_of_TCP_and_UDP_port_numbers). So your nmap scan means that something is listening on 23, and it may or may not be TELNET.
Nmap supports a mode called "version detection" in which it will actually start the opening handshake of known protocols to try to determine what protocol is listening. This can be very slow, for example if it knows about 100 different protocols and is scanning 1,000 ports, then that's 100*1,000 = 100,000 handshakes to try. So this option is off by default. You can turn it on with -sV. You can read more in the nmap man page; ctrl+f for "version detection".


Generating salt for hash that occurs on server and client

Would something like this make sense? If not, can you please explain why?

The process would probably require a hashmac instead of plain sha256. Plus, I would head up to crypto-hashing functions of your language instead of simple hashing functions (ie: password_hash in PHP instead of md5).

Last, you didn't salt your hash in your example: your salt = sha256(email) is the unsalt hash that attacker would like to know.

  Does this mean that even if salt isn't a secret nor random

By definition, salt is random, so question is contradictory

  it would still prevent the attacker from recovering email addresses from hashes using rainbow tables

No, because the salt must be random (and unique for each field).
If salt is not random and predictable from your original data, or if the salt is not unique, then rainbow table can be used (maybe attacker will need to forge that table first, so that's harder than no salt, but that's still doable).

  Because each email would be hashed uniquely.

But two calls of the hashing method with same data yields the same result, and therefore is a threat. If your "salt" is not random, you'll still have unique hashes (otherwise, write down your email because you've found a collision)but a rainbow table is meant to match one hash to one corresponding plain raw value, so you'll still be vulnerable (even if attacker will probably have to forge that rainbow table first instead of reusing one from the web).

So to fall back on your case, what you want is:

  An API that can tell if an email "exists" (is on a server's whitelist) without sending the email itself

If the servers knows the plain email, then you can let client generate a random salt, do a password_hash of that email+salt, and send this hash and the salt to the server. Server will then take each email it has, do the hash process, and if a match is found, then server returns "email exists" to the client.

If the server does not know the plain email, but only a salted hashed version of it, then you can treat this email like a password, which is sent in clear over secures connection.

If you still don't want to send the email in clear over secured transport, then you cannot send a random salted hashed value (it's the goal of random salted hashed values: have a unique result for each call, and not being able to get any information from that value, so server won't be able to get the information "this email is on whitelist"). Then, you will need an id for every hash, that will act as a unique public identifier of that hash (the same way login is a public identifier of server's hashed password). Server would then return the hash for this id and client will be able to password_verify it using the email it knows (so email is not transferred, but the hash is).


Algorithm to implement symmetric encryption in VB.Net for Windows and in Swift for iOS

AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) is the go-to standard for secure symmetric encryption these days, and is very widely supported (some libraries might still call AES "Rijndael"; just stick to 128 bit blocks and 128, 192, or 256-bit keys and it should be compatible). You can use AES with other modes, such as CBC, but this opens you to additional risks such as padding oracle attacks and additionally requires using another primitive (such as a secure hash function) to provide integrity for the encrypted data (using a construction such as an HMAC). GCM (if used correctly) authenticates the data for you, which most ciphers and "modes of operation" do not. However, GCM is somewhat tricky to use safely; there are alternatives such as [X]ChaCha20-Poly1305 (the ChaCha20 stream cipher - or its XChaCha20 variant - with an authenticated encryption) that are preferred in some implementations.

HOWEVER, having said that, you should consider using a library that already implements the crypto for you and was written, reviewed, and tested by experts. Crypto newbies should not attempt to use cryptographic primitives (such as AES) directly unless they have no other choice (it's just way, way too easy to screw something up; even experienced crypto developers miss things and it sounds like you don't even know what to look out for). One such library is "libsodium", although even it might be a bit much for a raw beginner. It is written in C but does have lots of bindings for other languages (including .NET and Swift). It includes functions to do everything you need.

Of course, once you've got your crypto library (third-party or hand-rolled atop the primitives), you still have the question of where and how to store/transmit the key. It doesn't do any good to encrypt something if the other side can't decrypt it, and it also doesn't do any good to encrypt something if everybody can decrypt it (which is what you'll get if you try doing something like hard-coding the key in the app). Using a password (via a "key derivation function") is one option. Another is to transmit the key (through a secure channel, such as HTTPS) to the server, but then the encryption isn't truly end-to-end; the server has everything it needs to decrypt the data, and if the server is ever compromised then the attacker will be able to decrypt the users' data too.

End-to-end encryption is hard to do right. Even a relatively simple cryptosystem is a massive pile of things that are easy forget or mess up, and a simple mistake can mean it all falls apart. As a general rule, if any of the algorithms or considerations I mentioned in this post are things you haven't heard of before, you should probably do some more reading before you try to write this code. I've seen lots of developers - even at big, highly-exclusive software companies with huge amounts of institutional knowledge - try to write their own cryptosystem and screw it up, often in some way that completely breaks its security.


Attacker knows what I do online and even has screenshots from my computer - how?

If all this is overwhelming to you, get a friend to help you or hire someone. Also, consider filing a lawsuit if you strongly believe this person is spying on you. This is illegal!

What can you do

Most likely the attacker got into your wireless network because you are using an old router with weak encryption or your chosen password is weak. He could have compromised devices inside your network afterwards, but that requires a more sophisticated attacker, making this scenario less likely. But not impossible! So here are the actions I would take:

If he nested on one of your devices, it could be close to impossible to find out how he did it. Easiest choice might be to reinstall your operating system from scratch. Also, if you have more devices in your network than just your computer, you might have to reset these to factory settings as well. But to be honest I'm unexperienced how to deal with a compromised smart tv or similar.
Note: This step is useless if your system is compromised. He can log your keystrokes and will know the new password! You should change the wireless password. If you don't know how, search online for the manual of your model. If you can't login, there's always a way to reset the device to factory settings, often by holding the reset button for a specified number of seconds. But be aware, that you'll then have to reconfigure the router yourself before you can use it again. You won't have wireless unless you finish the configuration.
Note: This step is useless if your system is compromised. He can log your keystrokes and will know the new passwords! You should change your online login credentials (hotmail, facebook, google, netflix etc.). Specifically those for the sites that this person is referring to in your conversations. This might be a great time to start using a password manager like keepass. There are also plenty of online password managers if you fear to accidentally loser your password database.

Help us help you

We could help you a lot better if you could explain why you believe that someone is inside your network. So here are a bunch of starting points for you:
 - What happened? When did it happen? What exactly did you observe?
 - What Wireless router are you using?
 - What wireless encryption are you using? You can find out by logging into the web interface of your router in case you did not know.
 - What devices are connected to your network? Television, smart phone, tablet, home server, raspberry pi, notebook computer etc...

Regarding mutiple firewalls

Running multiple software firewalls will not improve your security. You mean it well, but it could worsen your overall security. Typically when you install a software firewall, it will deactivate your windows firewall automatically. Decide for yourself which one you want to use. The Windows firewall is a legitimate choice.

Possible Attacks

Next I'll address your question what someone can do once he enters your network. This is most likely not a complete list:

The first thing to realize is, that this person now has the key to your wireless network. An eavesdropper can then read all your web traffic. Luckily HTTPS adds another layer of security such that your login credentials are encrypted between your computer and the server. There are however still websites out there which handle the implementation poorly or do not use HTTPS at all for the login form. In that case your unwelcome guest could obtain your login credentials. Even worse, if you are using the same credentials on other sites, he now has access to these as well if he finds out about them. This by the way is one of the reasons why you should use a different password for every website and maintain them with a password manager.
Your devices are no longer protected by your router with NAT. If you are running local network services or have a NAS, Smart TV etc. in your private network, the attacker could now communicate directly with them. He or she could find security exploits and compromise your devices. From there on, depending on your setup, everything is possible.


Handling security with sub-domains pointing to boxes

You shouldn't be exposing your server's IP, but your firewall's IP through DNS ...


The MAC address of the network card can only be seen inside the local network. I think you cannot be really anonymous inside a local network anyway. But apart from that most network cards can be set to a different MAC address using software.

  There are various ways to change your mac address with different NICs, but I would trust hardware more if it was specifically designed for anonymity.

The hardware has no idea when it should change the Mac address, so this has to be controlled by software anyway. Apart from that "hardware controlled" means actually controlled by firmware on the NIC, so in reality this is software again.


QR Codes do not convey this type of information. They can be used to encode arbitrary text, a URL, or a number of other structured content, but in the end it's just printed information.

A QR Code is no more or less secure than any other label printed on an object.


What are the reasons why TLS certificates are not issued or revoked?

While each CA does have their own policies and procedures they follow regarding when to issue and revoke certificates, there is a common set of Baseline Requirements which all publicly trusted Certificate Authorities are required (by browser vendors) to follow.

The Baseline Requirements specify the following list of conditions under which a CA must revoke a certificate:

  4.9.1.1. Reasons for Revoking a Subscriber Certificate

  The CA SHALL revoke a Certificate within 24 hours if one or more of
  the following occurs:

  The Subscriber requests in writing that the CA revoke the Certificate;
  The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant
  authorization;
  The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key
  Compromise or no longer complies with the requirements of Sections
  6.1.5 and 6.1.6;
  The CA obtains evidence that the Certificate was misused;
  The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of
  Use;
  The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no
  longer legally permitted (e.g. a court or arbitrator has revoked a
  Domain Name Registrant’s right to use the Domain Name, a relevant
  licensing or services agreement between the Domain Name Registrant and
  the Applicant has terminated, or the Domain Name Registrant has failed
  to renew the Domain Name);
  The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified
  Domain Name;
  The CA is made aware of a material change in the information contained in the Certificate;
  The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or
  Certification Practice Statement;
  The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
  The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the
  Certificate;
  The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made
  arrangements to continue maintaining the CRL/OCSP Repository;
  The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
  Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
  The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties
  (e.g. the CA/Browser Forum might determine that a deprecated
  cryptographic/signature algorithm or key size presents an unacceptable
  risk and that such Certificates should be revoked and replaced by CAs
  within a given period of time).

Source: Version 1.4.9 of the CAB Baseline Requirements.

Be aware that these requirements only say when a CA must revoke a certificate. They do not restrict CAs from revoking certificates for reasons not in this list. Individual CAs may have their own policies which specify other conditions under which they may revoke a certificate.

As for when a CA will refuse to issue a certificate, that question is much more complicated to answer. The main reason why a CA would be required to refuse to issue a cert would be when the person or organization requesting the certificate cannot prove they are who they say they are. The details of what sort of identity proofs are required, and other conditions under which a CA must refuse to issue a certificate are, again, specified in the Baseline Requirements.

As far as I am aware, the Baseline Requirements do not require CAs to monitor whether the people or organizations they are issuing certs to are using them for illegal activities. Law enforcement is not within the scope of a CA's responsibilities.


Client-side attacks with custom malware in penetration tests

You don't need a self spreading malware in order to test the end user machines. For example, if you decide to target the end user machines browsers, applications (MS Office, PDFs, Java, Flash) or physical security of the machines, what you need is a custom exploit and a payload. The payload need not to be self spreading. You just need a type of payload that give you control over only the machine you have targeted.

Let us take an example. Suppose I want to target 10 user machines and I decided to target the their browsers. The first thing I would do is I would host the Metasploit exploits on my machine. The exploits needs to be customized in order to bypass AV and other types of defenses. I can use meterpreter as my payload. Then I would send these 10 users a link to my server which is hosting the exploit files. If out of these 10 users I managed to make 5 users connect to my Metasploit server and I successfully exploit their browsers and gain access to their machine, the meterpreter is going to give me access to only those five machines. It is not going to target every other machine in the subnet automatically. Off course if I want to pivot further from there, I can do it manually.

So in the end, I think what you need is a custom malware but that custom malware don't need to be self spreading. Make a malware that is only going to give you access to the particular machines you are targetting.


How can an email sender include his PGP key, so I can answer with an encrypted mail?

If the correspondent's key is posted to a public key server, e.g. pgp.mit.edu, your email client can probably find it.  If not, the correspondent has to to supply it.  Read carefully the answer by fgrieu concerning trusting keys supplied in message from another.  It's not safe.

(You should consider posting your public key on a key server, too, and read about PGP/GPG key signing: https://www.google.com/search?q=pgp+key+signing because a signed key is less susceptible to attacks that replace your key with another's.)


TLS 1.2. Handshake: Where do Client and Server negotiate how the master key is built from randoms and pre?

At the end, I didn't had to rebuild it manually. I used wireshark and its automatic decryption tools to build the master key and extract the desired information.


My iTunes account got hacked and someone used it to buy in-app purchase. How could that happen?

You said that you are worried that your notebook might be infected in addition to worrying about your iTunes/Apple account being compromised.  That, in combination with the fact that I always assume the worst will be the basis/context for my answer to you.

I always assume the worst as I stated so here is what I would do:

1)  Wipe your notebook; if you suspect any kind of compromise or any kind of malicious infection at all then your safest bet is to wipe it and start over.  Are there other options here such as trying different scans to try to "potentially" find the compromise?  Sure.  Could it take forever, and possibly not yield fruitful results?  More than likely.

2) Change your iTunes/AppleID password right away.  Create another string of randomly generated characters that include the usual: uppers, lowers, special characters, and numbers.  May I suggest a password manager?  If for nothing else, use the password manager to generate a random password as most of them have this capability built-in to them now.

3) Update your security questions on the account to completely different questions and answers than before.

4) Turn on Apple's two-factor authentication.  This is purely OPTIONAL, however it's a great additional layer of security nonetheless.

5)  Practice safe browsing and computing habits going forward.  I know this is pretty broad and generalized, but the more you're aware of what sites and services you visit and use and their practices as well as their reputation while online, or even offline for that matter, the safer you'll stay in the long run.

These are just the general overview items.  Please let me know if you'd like any more in-depth.


You have to differentiate between email clients and web based email.

Email clients request that the server sends an email that was composed remotely. This is the case with Thunderbird and others. You logon to the destination SMTP (Send Mail Transfer Protocol) server and issue commands to send the email you desire.

With a web based solution, such as Gmail, Hotmail (Outlook), and so on, you are effectively logging in on the destination server. Because the server itself is issuing the commands to itself, there is no "client" in this case.

As dictated by RFC 882 (and it's parent standards documents), all emails are to have "email headers". You can read more about them using the two links below.

To remove the "client" headers use a web based email service, or create your own web based email service.

Web Links:

https://tools.ietf.org/html/rfc822

https://tools.ietf.org/html/rfc5322


The question you're effectively asking is what are the dangers of allowing every file on my server to be readable by anyone?

This has a few serious implications, the attacker could:

View stored passwords - if, for example, you run wordpress the attacker could easily gain access to your username and password for your database server (e.g. wp-config.php)
Gain information that could be used in further attacks - /etc/passwd may only contain usernames but that could be enough to start a brute force attack. Log files could also be read giving addresses of the user. Encrypted password files could be bruteforced offline.
Read private information - if your website consists intellectual property (i.e. source code, e-mails) this could be easily read by the attacker.

Basically whilst your attacker hasn't technically gained root access they have gained access to a wealth of data. This data could either be used in other attacks or (depending upon the aims of the attacker) could be enough.

There are almost certainly situations there where this vulnerability would be as bad as the attacker gaining root access. The security priority for a server may be for it to not reveal the system's source code, if this vulnerability were present then for those cases the worst possible attack has occurred.


Is locally reusing a password a bad practice?

The point about not reusing passwords is damage containment. You do not want a breach in one system revealing a password that grants access to other data and systems that would otherwise have remained secure.

If the two usages ultimately protect the same data, then it makes sense to use the same password. Your case is a bit different: the two usages are "cascaded". By encrypting your backups, you are applying an extra encryption layer over that which is already provided by KeePass and VeraCrypt. If your master password is strong, that extra encryption layer is redundant. You could make unencrypted backups.

Arguably, you should make unencrypted backups, in case the encryption system for the backups happens to be weaker than the one used by KeePass. When doing password-based encryption, the password must be processed with a proper password-based key derivation function (see this); KeePass makes an effort and the iteration count can be configured. If the encryption system is not as robust as KeePass in that respect, then it may help the attacker: the attacker will run his dictionary attack on the backup, and once he found the password, he can then apply it to open KeePass and unlock the VeraCrypt modules.

Summary: if you can make sure that the backup encryption system processes the password in a way which is at least as resilient as KeePass to dictionary attacks, then using the same password is harmless. Otherwise, it can be harmful and you should abstain; i.e. encrypt with another, independent password, or don't encrypt backups at all.


SHA-1 deprecation and impact on self-signed certificates

As an organization, you typically have control on the policies implemented in your infrastructure, this includes policies governing the behavior of client software regarding certificate handling.

I am assuming you discuss the classic browser - web service relationship. With this in mind, take a look at the two main player's statements on this matter:

https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecation-roadmap/

https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html

Even so, depending on the type/version of your clients, enforcement of bypass policies may be possible. Not that this would be an advisable course of action.


how to protect my data from malware/spyware that infected my BIOS?

The only way to get control over your computer, that works always, is to physically replace the infected BIOS flash chip with a non-infected one (provided that only the BIOS is infected). It is possible that the flashing utilities aren't infected by the government, so you can perhaps even flash a non-infected BIOS from inside a system, which comes with its own problems to solve like how to acquire such a firmware, or by accessing the needed flashing bus via hardware tools, but generally, there is no cheap way to "bootstrap trust" out of distrust about hardware.

You will have to find out how exactly, and how deeply the government infects your computer with their spyware, and then try to counter that, the only general answer to this is to replace the actual hardware parts.


it will be a very good idea if you use a proxy server in your home network that will help you controlling web traffic and view the log file which contains the trace of connections I personally use Squid as a web Proxy and Sarg as a log analyzer .


802.11 Authentication/Association and WPA/WPA2 authentication (Four-way handshake)

WPA2 is just a commercial name for a complete implementation of the 802.11i specification (WPA implemented only a part of it as a temporary measure against WEP weakness).

802.11i is an amendment to the original 802.11 specification, which means that it replaced several part from it, the original content becoming deprecated and a new revision of the 802.11 being edited.

More specifically, 802.11i introduces the concept of Robust Security Network Association (RSNA), and distinguishes between pre-RSNA security algorithms (WEP and 802.11 entity association) and RSNA security algorithms (the more secured algorithms allowed by WPA2).

Your hardware and software may offer pre-RSNA and RSNA security, usually as drop down menu allowing to select either WEP, WPA or WPA2. Your configuration here will define which algorithm you use, but at a given time you will use only one of them, they are not cumulative and will not be used at the same time.

For more information, 802.11i amendment can be found here (as per the current subject you directly jump to the "Security" chapter), and all successive amendments have been merged in the reference 802.11 specification (including deprecation of TKIP, which after all was just a temporary solution designed for WPA).


How to interpret SELinux boolean allow rules?

What exactly is your question?

Basically what i think sesearch is trying to tell you is that you have two options if you want to allow httpd_t type associated processes to "read write" httpd_sys_rw_content_t type associated "files"

Either you set these three:

httpd_enable_cgi
httpd_unified
httpd_builtin_scripting

Or you set this one:

httpd_builtin_scripting

Which obviously does not quite seem to make sense since the former is a super set of the latter. The policy author may or may not have made a mistake there.

The former set of booleans may have the same rules as the latter boolean as part of broader permissions. Your query was quite narrow and so it matched both scenarios

You could use sesearch to see what rules are associated with each of the booleans and then determine whether setting the first three or setting the latter one is in your favor

Granted that this seems to not be very intuitive, but sesearch gives you accurate and to the point info.

The web server policy used commonly by distributions aims to be a general purpose policy, and that makes it pretty complex and introduces some trade-offs. There are many different way's to use web servers. The booleans, and types give you some flexibility but if you want to have a policy that is tailored to your requirements then you can always choose to write your own policy for your web server. Unfortunately that might not be as easy as it should be but it is possible.

As for why things "did not work for you", I would have to see some AVC denials to be able to interpret the events and suggest solutions.


Why shouldn't I sign my email newsletter using an s/mime email certificate?

Signing emails is useful only insofar as recipients verify the signature. Theoretically, signing the emails might improve deliverability, but only if a recipient configures his filters for incoming emails to verify email signatures and accept emails which have been verified to come from you. However, this is only theoretical; in practice, email filtering is not under control of the end user, but done in the email server, and no server verifies S/MIME signatures. In fact, there are some (poorly configured) antispam system who will react negatively to signature (because they don't understand them), so signing emails is probably a bad idea in your case.

Said otherwise: if signing emails improved deliverability, then spammers would do it.

Another general comment is that you should not want to sign. When you sign something, you are actually building a legal weapon aimed against you: a signature can only serve one purpose, which is to rub your data in your own face. If you think clearly about signatures, then you should actively avoid signing anything; what you want is that other people sign what they send to you.


DDoS attack - where are packets dropped?

You're correct that if the packets are reaching your server that the attack has succeeded, mostly. Many businesses will purchase DDOS protection from a company that will drop such packets for you before they reach your precious pipes.

One such company and how the service works, very broadly.
https://www.cloudflare.com/overview


Where do I report a friend's email account that has been hacked?

The account has probably not been hacked, but the source address is being spoofed.  (That is, the sender has forged your friend's address in the from line.)  The From line in an email header is approximately as trustworthy as the return address on a piece of physical mail: you can technically write anything you want there, regardless of how well it meshes up with reality.

If you really believe your friend's email has been hacked, they should change the password of that email account, and the password of all accounts linked to that email account.  If they can't get back in to the account, they should contact the email provider.


No, anybody with a computer
Sometimes
If it is connected to a network, yes. IOT is an emerging threat now.

You just have to know what to look for. You can find an insane amount of information using wireshark, Cain and Abel is pretty ridiculous too on active networks, it does the parsing for you.

Wireshark for example - say you captured traffic for a while and your looking through and see a telnet session (port 23) - you can right click on a packet of that session and select Follow TCP Stream and there is a chance that you end up with someones password. I'm sure someone could provide more detailed examples but, hopefully that gives you an idea.

https://www.youtube.com/watch?v=xShwyUq-uHk - Video on what I described (telnet)

Cain and Abel - in my experience is like the laziest recon tool ever. I was sitting in a computer lab way back in the day and just messing around being a nerdy teenager. Every new account that was being created or entered around me I had a record of. At first I thought, wow, this is way too easy it must be wrong. So I shouted across the room, "Hey, Girl X - did you just create a Zanga account?"...I had her username and password.


Microsoft account comprimised and someone did automatic sync and wondering if emails downloaded?

From what I can see, yes your emails have been compromised. If you look at the log you notice that it has synchronised IMAP - This suggests that the client has downloaded your email settings, folders and all of the emails contained In those folders.

If you didn't know already IMAP is a popular protocol for incoming emails.


Someone borrowed my phone and Im scared its hacked

I think here is not the place to ask this kind of question.

Anyway, I don't think it is possible to hack a phone with a couple calls (yet). Should you notice any suspicious activity in your phone bill you can ask for help in your telephone company. In case your phone behaviour is odd, you can factory reset the device, which should erase anything that might have happened.


My college hosts a critically vulnerable service. I warned them 4 years ago. What should I do?

If you are no longer a student in that college, then you could sue them for not applying due care in the handling of your personal data. Technically you could also do that if you are still a student there, but no longer being a student means that they would have a harder time retaliating if they are so minded.

The crucial point here is that being a potential victim gives you an acceptable reason for putting your nose in these matters. Otherwise it would be all too easy to flag you as an Evil Hacker™ and handle the problem by throwing you in the lawyers pit, instead of actually fixing the software.


Security Benefits of Reverse Proxying Java / Tomcat WebApps Locally

Focusing solely on the (claimed) security benefits. There are multiple elements to this. I'll address each in turn.

Robustness against attacks that utilise malformed requests. The thinking here is that the reverse proxy does a better job of rejecting malformed requests and therefore does a better job of defending against attacks that depend on the server incorrectly handling the invalid request. In my opinion (as a Tomcat committer) I do not support this view in the case of Tomcat. Where it could apply is if you are using something (doesn't have to be Java based) that isn't intended to be internet facing to host your service. Then fronting with a reverse proxy makes sense.

Simpler TLS configuration. Certainly true historically when certificate authorities tended to provide certifications only in PEM form the conversion process to a Java KeyStore was not well documented. There have been improvements across the board on this. Certificate authorities are providing Java KeyStore specific instructions, Java itself is moving away from KeyStores to PKCS12 and Tomcat can use certificates in PEM format (the same format httpd uses). In my view this point doesn't carry much weight these days.

The reverse proxy offers more configuration options. This is generally true. If you need to block a header, integrate with an external authentication and authorisation system, modify a response then while you can do all of the above with Tomcat, you will need to write some code to do some of these things in Tomcat that you can do with configuration in the reverse proxy. How important this is to you will depend on what it is you are trying to achieve. One benefit I have seen is that when a new vulnerability emerges, you can often configure the reverse proxy to block the attack (e.g. with modrewrite) more easily than Tomcat.

The counter argument is that by adding a reverse proxy you are increasing the attack surface. Now you need to worry about vulnerabilities in the reverse proxy as well as your Java component.

You also need to ensure that the reverse proxy is configured correctly - especially if the reverse proxy is terminating https and then using http to the back-end. You need to be very careful to ensure that the back-end knows which requests were received (by the reverse proxy) over https and which over http otherwise you'll open yourself up to a bunch of potential vulnerabilities such as leaking secure session IDs over http.

Generally, it is probably more important to stick to what you know. If you are an experienced httpd administrator who is happy setting up httpd instances securely then you are more likely to end up with a secure configuration if you proxy through httpd rather than try and configure something you don't know. Likewise, an experienced Tomcat administrator is likely to end up with a better result with just Tomcat rather than adding an unfamiliar reverse proxy.

Overall, I suspect that the non-security arguments for using a reverse proxy (load-balancing, exposing multiple services through a single hostname) are likely to drive the decision whether or not to use one.


What are the most sophisticated techniques used by intruders you have found in the wild?

Bog standard virus outbreaks have rootkits, backdoors and covert channels.  It's hard to tell if anyone is even utilizing them since the encrypted communications to the command and control is mysterious enough, and the depth at which you'd have to research it puts that kind of analysis outside of practical security.

Oddly, the IDS didn't pick it up, nor did the traffic pattern analysis... which is IMHO, shameful.  The AV picked it up when the healthy systems got updates and saw infected files on shares.

It would be embarrassing... if the problems were in my control.  I was only responsible for cleanup and documenting the problem.  My recommendations were mostly ignored, but it was executive risk assessment which made that call and I respect it.

I was of course put in front of the firing squad to explain to executives why the IDS system didn't detect anything when a toddler with wireshark could see that all hell was breaking loose.


Is there any added benefit to using a random keyfile of more than 512 bits?

Short answer: no

Long answer: For plain mode, the manual for cryptsetup states in the "Notes on Password Processing" section:

From a key file: It will be cropped to the size given by -s. If there is insufficient key material in the key file, cryptsetup will quit with an error.

So unlike passwords entered from the terminal or stdin, the keyfile is not hashed, only cropped, so you'll get no extra entropy out of a longer keyfile. cryptsetup will even warn you about this if you try to specify --hash plain in plain mode with a keyfile.
For LUKS mode, it will read the keyfile completely (up to --keyfile-size, defaults to 8192 KiB) and hash it, but you won't get more entropy with longer keyfiles as long as your source is good enough.


Is having a piece of paper with 2 fake PINS a good solution to mitigate credit-card theft?

Anything you can do to mitigate the threat of usage after the physical-theft of the card is a great idea. Making them take longer by making them make mistakes and/or trying in multiple places is a solid idea. That is, aside from the ultimate mitigation of keeping your bank's phone numbers in your phone so you can contact them immediately to report card theft. As a piece of Social Engineering it's not the worst idea I've heard. Keeping that piece of paper in your wallet with the card might be a little more difficult and not worth the effort, but I could see it working.

In places where ATMs retain cards after several failed PIN attempts, this could be one extra level of security that might put less strain on your financial resources. Several card carriers also support larger PINs, up to 16-digits in some places. So you could enhance security on your card that way as well. You could also keep multiple closed credit cards in your wallet so it takes longer for the would-be thief to make an attempt on your good cards.

That being said, I don't know how often you expect to have your card stolen, and taking steps to prevent its theft in the first place might be more effective than a Social Engineering attempt at mitigation. Locking your wallet in a drawer at night, keeping it in your front pocket or carrying it in an odd location on your body (sock, inside your button-up shirt, secure pocket with a zipper) might be better techniques to avoid the theft in the first place.


Are Three attempts to block login a good idea?

While Rory's answer is pretty much spot-on, I'd also add that account lockout after X attempts, in certain contexts, can be an easy way to cause a denial of service (DoS) against a legitimate user.

Imagine if a webmail provider (like gmail) worked this way.  If I want to cause you a temporary DoS, all I'd need to do is try to login as you with three (or 5, or however many it takes... the actual number doesn't really matter too much) times with the wrong password.  The webmail provider would then lock your account and when you, even though you know your password, went to log in, it would not authenticate you.

This is why such lockout policies aren't too common with publicly-accessible sites these days.  A better approach is to put an increasingly larger delay between password prompts, which will deter script-kiddies but still allow you a chance to enter your password. Even better is using another factor, like the source IP of the login attempts in deciding to slow-down the login prompt (or display a captcha in the case of Google accounts).

Just something to think about when debating this type of policy.  Cheers.


I am unaware of an MTP SD Card reader, and cannot find anything listing the USB reader having this support. So, instead, I would suggest using an Android device, which has micro SD card support, as Android supports MTP. USB mass storage instead of MTP outlines doing the opposite of what you want but gives an idea of how you can use Android 5.0 to mount a micro SD card in MTP mode.


How "leaking pointers" to bypass DEP/ASLR works

"Leaky Pointers", more commonly known as "Dangling Pointers", is useful to create an attack chain to bypass a layered security system.
The idea behind DEP is that you are making regions of memory non-executable,  such that shellcode in this area cannot be executed.  DEP alone is really easy to bypass,  you can just ret-to-lib,  and call any function you would like,  system() is a favorite.
However,  under Windows, ASLR enabled libraries will have a randomized memory space,  so the attacker won't know the memory address of the system() function,  and therefore cannot call it.  The idea behind ASLR is that it doesn't matter if you can control the EIP if you don't know where to jump to.
Being able to read the location of a region of randomized memory undermines the protection of ASLR,  because now you have a reliable jump location.  This can be accomplished though a wide variety of methods.  Using a buffer overflow to simply overwrite the null terminator and read past the end of an array has been used in pwn2own against IE.  But really the most common technique is using a Dangling Pointer which can be used to read/write or even execute a valid memory location despite ASLR.
Even with ASLR,  not every memory location is randomized.   In fact the executable binary has a predictable layout,  so you can use the executable against itself in a ROP Chain.  However sometimes it's difficult to find useful ROP gadgets, especially if the target binary is very small.  If you are unable to build a useful ROP Chain,  then a memory disclosure vulnerability,  such as a dangling pointer,  is a great method of attack.  It's important to note that ASLR only randomizes the location of the page (the first few bytes of the memory address.) If you can populate a region within this page with your shellcode then it may be possible to accurately execute your shellcode by using the leaked memory address as a base and then hopefully your shellcode is at some offset of this random location.
Using chains of memory manipulation vulnerabilities is unusually only possible inside a scripting environment, such as JavaScript.


Internal CA for Digital Signature Solution - PKI Based

Microsoft's Certificate Services is a CA. It does its job reasonably well(*) as long as you comply to "the Microsoft way", which means Active Directory throughout, with domains and forests and federation. This usually implies several dedicated servers.

As for open-source solutions, I heard good things about EJBCA. Some people try to do PKI "by hand" with OpenSSL (the command-line tool), but this means that you will basically write your own PKI (95% of PKI is procedures, not software) and this requires a thorough understanding of the arcanes of X.509. This is not a good plan for the unwary.

(*) Except that it does not scale well at all; the CA becomes sluggish after 50k issued certificates, unusable at 300k.


Does LoraWan protocol's Over The Air Activation run Diffie Hellman?

Let AppK the Application Key. The Application Session Key (AppSKey) and the Network Session Key (NwkSKey) are generated by using only the AES algorithm without adopt the Diffie Hellman protocol.

Let us suppose that we have a Device Node that generates a 16 bits pseudorandom nonce namely DevNonce. This nonce is sent to the application server. The application server generates a 22-bits pseudo random nonce namely AppNonce that is sent to the Device Node.

The Network ID, called NetID is pre-shared between the entities. Moreover a standard 32-bit code (for NwkSKey this is 0x01, for AppSKey this is 0x02) is used.

Finally the resulting message is padded to 128-bits.

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)
AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)

However I advise you this link to deepen the LoraWan Security.


SSL Labs report question: Is "Insecure Renegotiation" possible if weak cipher suites are not available on server?

"Insecure Renegotiation" is not about cipher suite selection; it is about a kind of Man-in-the-Middle attack that goes thus:

Attacker connects to the server and performs a first handshake.
Attacker pushes some data (e.g. an HTTP POST request).
Client connects to attacker and sends its initial handshake sequence.
Attacker forwards the client handshake messages to the server and back. From the point of view of the client, this is the initial handshake; from the point of view of the server, this is a renegotiation within the context established initially with the attacker.
From that point onward, the attacker blindly forwards data back and forth. The server initiates some authentication mechanism with the client.
The server erroneously considers that the authentication result covers the complete dialogue, including the data that the attacker pushed before the renegotiation. As a result, the server may apply the attacker's request as if it came from the authenticated client.

RFC 5746 is a mechanism (a TLS extension) that aims at making initial handshake and renegotiation handshake distinct. If supported by both client and server, then the server, in the scenario above, will notice that the ClientHello in the second handshake is tagged as "initial", not as "renegotiation", and will thus reject the attempt. When some report tells you that your server does "insecure renegotiation", it really tells you that your server does not support RFC 5746. This is completely unrelated to cipher suite selection, and there is no change in your list of cipher suites that will do anything for or against that; this is an orthogonal setting.

One may note that allowing insecure renegotiation does not necessarily imply an exploitable hole. It really depends on how the server handles user authentication, in particular with regards to renegotiations. Conceptually, a server who receives an unauthenticated request may initiate a renegotiation (e.g. with certificate-based client authentication) and then, after the second handshake, send an HTTP redirect so that the client sends the request again. In such a case, there would not be any problem with lack of support of RFC 5746. However, existing Web servers do not operate that way, hence a common need to "strengthen" renegotiations systematically at the TLS level.

(In general terms, the problem with renegotiations is that SSL/TLS provides security only in the chronologically forward direction, while users of SSL/TLS, i.e. Web server, commonly assume that security extends backwards as well, even across renegotiations. RFC 5746 fixes a known, explicit attack modality, but it is unclear -- or at least undocumented -- whether it really ensures backward-facing authentication up to the initial handshake.)


Is router pinging local hosts normal functionality?

A router often needs or wants to know what/who is on it's network.  There are several routing protocols that need to know things.
If it is only two then that is strange.  An attacker would likely ping or nmap the whole local network.  A router likely would be doing this on an automated basis.
This might be a better question for https://networkengineering.stackexchange.com/


What are the main security concerns for Enteprise Software running on internal networks?

Data classification will largely drive the requirements. An enterprise will adopt a data classification system to help identify which systems need which protections.  We can assume your question applies to sensitive data.  Even then, different requirements apply depending on the source of that data and the classification.

Sometimes, outside forces dictate the requirements.  For example, due to the type of data we work with, we are audited every year by an outside party.  They require, among other things, that we pass scans by Nessus and AppDetectivePro.  So, to ensure we pass, we run those tools against systems in scope.

"Before you sign the check" is the time where an enterprise would make sure they have permission to do the required tests. For example, the contract might require the vendor to provide a test environment to run invasive application security scans.   The procurement process might require that these scans be allowed before the product is purchased.

Vendors can be asked for proof that they've complied with standards.  For example, vendors to the federal government must meet FedRAMP requirements.  Cloud vendors are judged against SOC 2 requirements.


Learning recommendation for Enterprise PKI design and management?

Generally speaking, "shopping list" questions are frowned upon on Stack Exchange sites, because they don't map well to the Q&A format; they cannot have a complete, definitive answer, and any list unavoidably deprecates over time.

However, we can still say a few generalities (i.e. answer the meta question, aka: "how would I find good information ?"). PKI is 5% cryptography, 95% procedures. "Procedures" are what humans must do, in order to setup the CA, and in order to run it afterwards, foremost of which being the key ceremony from which the security is bootstrapped (see this answer). Though procedures are paper and humans and audits and more paper, they can only work within the limitation of the tools, i.e. what the PKI software and hardware offers. As such, the right place to begin is the manual for the core PKI software. For instance, if you want to use Microsoft's technologies ("Active Directory Certificate Services"), then start there. If you want to use EJBCA, start there. If you want your PKI to be a couple of handmade scripts around OpenSSL, then... you are not serious.

On a more meta point of view, I'd say that there are two ways to install and run a PKI properly:

Try to do it by yourself, using books and Web resources, and painfully making all the possible mistakes until you have really understood what a PKI is.(*)
Hire someone who applied the first method, and now knows.

In my own case, I find that detailed notions of what happens under the hood help a lot with debugging. So writing your own ASN.1 parser, and certificate validation engine, will grant you enough information to get a clue about what works and what does not in a PKI; you will also thoroughly hate X.509. Start with RFC 5280, which will teach you the jargon and show you what certificates can do and what they cannot. Complete that with the X.509 style guide; it is from year 2000, and thus ought to be obsolete, but is not, which says a lot about X.509.

(*) If you remember that authentication is not authorization, and therefore that trying to manage access rights through certificate revocation does not work, then you will have avoided two years of tears and teeth grinding.


Am I understanding correctly how to stop a certain OAuth2 session fixation attack?

Reading http://tools.ietf.org/html/rfc6749#section-4.1.1, this is what I interpret:

The client (in this case, the server with an account that Mallory is fixating) directs the user-agent to an OAuth request. state has been determined by the client, and is passed with the request, and will be passed back when the user-agent is sent to redirect_uri with an authorization decision. What the recommendation you quote is assuming is that each user-agent has a session tied to it, and that the state can either be calculated from that session identifier (hashWithSha1(the-session-cookie-value)), or is stored in a way that is keyed to that session identifier (for example, a session[:oauth_request_state] value on a Ruby On Rails server, that might be set to some nonce). Mallory, with her own session, will cause a different state value to be passed than Alice's interaction with the client will expect, and this will cause the auth to fail.

Please insert here all the usual caveats about believing people on the internet, and may anyone swiftly correct me if I am wrong.


I would take a look at this tool (I haven't tried personally though):

https://github.com/SaschaWessel/rc2-40-cbc

  rc2-40-cbc
  A brute force tool for 40 Bit RC2 encrypted email messages.

  In S/MIME messages [1] the plaintext is encrypted with a symmetric key (e.g. 3DES, RC2) and this symmetric key is encrypted with an asymmetric public key (e.g. RSA). To decrypt the message, only the symmetric key is required and this key can be brute forced for small key sizes. This tool implements this for 40 Bit RC2 keys.

  [1] S/MIME Version 2 Message Specification: http://tools.ietf.org/html/rfc2311


How does Google know who I met and in what room?

Facts

If you type the building address on Google map Your wife's doctor name appear but not the others docs working in the same office.

Google map

If you know the other doctor's names, try to search them on google map.
By doing this lookup, we can eliminate the possibility that this doctor of yours is the only one among his colleague who is registered on google map.

If none of the other doctor's name point to the building, you can assume that, for google map, your wife's doc is the only one who works there.

Google map relies on its users, it waits for them to feed the app with data. For example, if I activate the location on my phone (Android), Google will trace my movement, ask me to rate the place where I eat, if my work office has an elevator, or if my train station is open still open at 1 am.

Most of the time google map questions are accurate. On rare occasion, the app has misunderstood my movement. For instance, I was chilling in a coffee shop, the app thought I was in the dentist's waiting room next door and asked me if patients can receive a treatment without an appointment.

Google is a data gathering freak.

Answer

Being logged into her Google account, your beloved one went in the building with the location activated on her phone.
Your wife's doctor, you or your wife book the appointment in google calendar using Mail address that Google knows about.


It is a rather old tradition not to tell people whether specific logins exist or not. This is why Unix or Windows systems, when asking for user credentials, will respond to any error with a generic "wrong username or password" message. The idea comes from a rather old-fashioned vision of attacks: envision a bad guy who wants to enter a mainframe, and succeeds in getting his hands on a serial terminal plugged to the system, or maybe a telnet interface over a modem line. This attacker will be in a position of an online dictionary attack: he will try to guess a pair login+password which grants access. The administrative login names like "root" were usually better protected than normal user accounts (the "root" user was better at selecting strong passwords, or at least so it was surmised) so attackers would try to find normal user accounts, and, in particular, normal user account names.

Watching the movie War Games (from 1983) gives you a good idea of how things were.

Note the critical point: in the attack scenario above, the attacker wants to obtain at least an account, but could not get one under normal conditions, or even know who has an account.

It is now 2013, three decades after that movie. We have servers where everybody can register for free, and get an account. Obtaining one account is thus no longer an attacker's goal. Instead, the attacker will want to access specific accounts, with known identities. This is not the same situation. The context has changed. Therefore, old lore is not necessarily applicable.

Anyway, when a user tries to register on Facebook, he expects the process to work. At that point, the process may fail for only one plausible reason, which is an email address already used. It would be difficult to hide that fact from the user...

If we want to "protect" user email addresses, then the registration process must go thus:

User enters his alleged email.
An email is sent to that address, containing a one-time registration link; however, if the email is already registered, then an email is sent explaining that fact. No clue is written on the response Web page as to whether the email already existed in the system or not.
The user registers by following the link from the email.

Such a process would double as an email verification process, so that's kind of good. However, it has some latency (user must get out of the Web site, open his email reader, and wait for the incoming email), so this can be problematic for shopping sites (users are not patient, and they are prone to go shop elsewhere if they find the checkout process too cumbersome). Also, there must be some guardrails to avoid this registration system to be abused into a spamming machine.

I think it can be said that, for Facebook maintainers, making the registration process as smooth and quick as possible is more important than the user's privacy. Really, who would that surprise ?


how to update GPG private key that Pass uses

After looking closer at the man page you can update the public encryption key with:

pass init [ --path=sub-folder, -p sub-folder ] new-gpg-id


Data needed for why not to load third party JavaScript on web page with credit card form

Most ecommerce sites include google analytics code on payment pages.  Payment pages are also a prime candidate for a/b testing using JS tools such as optimizely or visual-website-optimizer.

There are also integrations to third-party product subscription engines that rely on JS passing CC data from the cart back to the service's mother ship (e.g. Ordergroove) via https.

Many ecommerce platforms make it easy to include a widget on all pages via a templating system, but difficult to exclude just a single page in the conversion funnel.

One option might be to wrap your widget in a bit of JS that ends up NOT including your remote code in instances where the URL matches a specific pattern.  This would allow your customers to place the code everywhere (in all templates), while easily preventing the execution of your code on specific pages.  This could be delivered as alternate installation instructions.


Is there additional security value in using passwords with words or phrases in non-English languages?

It entirely depends on your attack model. A 16-character word is likely to resist brute-force, but might fail immediately against dictionary attacks. How do you define the strength of that password? There's no single answer.

With the scheme you mentioned, a brute-force attack would be largely infeasible assuming your password is long enough. Even then, it's entirely reliant on whether the attacker is targeting your particular Unicode range, or if they're just going for ASCII.

In general, attackers in the "low hanging fruit" model are likely to guess passwords only in the ASCII range, because they're the most common. When 30%+ of passwords are in the top 10k list, why bother doing anything fancy?

However, if you're worried about attackers who know your language and are actively attacking passwords using the same model as you used to create your password, then you might run into trouble. Even so, if your words are sufficiently randomly chosen, and one of them isn't strictly a dictionary word (e.g. a word like "pwned") then you may well be safe. It's quite difficult to judge the strength of passphrases, since their security is largely reliant on unknowns such as the dictionary in use and the potential for mutations.

The truth is that we don't really know if they're secure against in-the-wild attackers in general, because we don't have any solid statistics to back up our intuition. The best advice I can give you regarding non-English passwords is to assume that they were English, and ask yourself whether you'd still trust them.

For further reading, we have a few related questions on the site:

Password complexity policy for non-English passwords
Non-English password dictionaries


Is Telnet safe for receiving text or does it compromise my whole network?

One issue with telnet is that there's no protection of the data in any sense. Anyone on the path can copy the data, alter it, and nobody will know. Any data coming from it is untrusted.
The rest of the network being compromised is not the main risk, because this is inherent to any service you have: HTTPS, SSH, NTP, anything. If someone can connect to your service, a bug on said service may lead to compromise. The word may is key here.  Some services are stable, secure, and run for years without issues, while others (sendmail, I am looking at you) have a constant stream of issues.

Apart from an SQL injection attack are there any major concerns I should be worried about regarding the rest of my network being compromised.

Here there's a lot of things that may go wrong:

Buffer overflows: this depends on how your application manages the incoming data. A buffer overflow, use-after-free, off-by-one and a lot of other memory access issues can lead to code execution and lateral movement on your network. The same applies to any other service.

Data leakage: anybody sending data to your service is subject to have their data stolen.

Corruption of data: any message can be silently changed in transit.

Replay attacks: data can be copied, and re-sent later.

What do you do? You can ask your clients to run an encrypted tunnel between their network and yours, and send the telnet data inside the tunnel. Because asking the clients to upgrade their services is not something they will do. SSH is around since 1995, HTTPS since 1996, and they still use telnet, so I bet they will keep using telnet until the end of the times.

cyber security audit by an external company said it was a massive risk to our business.

Ask them to clarify the massive risk. Most of the time, the massive risk they are talking about is credential theft, as telnet is not encrypted and any credential sent can be stolen. If you tell them that no credential is ever sent, maybe they change the risk assessment.
But even so, create an encrypted tunnel and FORCE your clients to use the tunnel.


OAuth2, SAML, OpenID connect - Which one to use for my scenario?

OAuth2 is a framework for authorization, if your request is about the identity of the users then you should consider using OpenID which is part of the global framework OAuth2, but for a special use case: authorize access to the identity.
As for SAML, you can configure one of your servers as identity provider and the other as service provider, but the hard part will be assigning different roles for the different servers A and B.
OpenID can be more easy to use when you have roles or scopes to exchange, you should install an SSO solution (like openam, gluu, keycloak) on your server A, users will be redirected to authenticate, and their session will be valid for server A (or a seperate server), as for server B an OpenID request is sent by server A to server B, which will contain a request for authenticating the user, with scopes relative to server B, for example:
  curl -k --data "grant_type=password&password=1234&client_id=app-profile-vanilla&scope=scope_sever_B&username=100000&client_secret=578262e1" http://localhost:8180/protocol/openid-connect/token

Result: {"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJCaTM1c2VPQTh4c290bzQ5eTMwTXNpNVZ6MW...","expires_in":60,"refresh_expires_in":1800,"token_type":"bearer","scope":"email profile scope_server_B"}

This example is just to demonstrate how its works, in your environment you should use authorization code flow, which is the default flow for a user, and since the user is already authenticated to server A, the authorization server will pick its session and created another one for server B, without the user having to do anything.
Another advantage of using OpenID is that in case you wanted to add more sites, the configuration to include them in the sames process would be very easy (create an OAuth2 client, configure scopes, configure the new server), which is relatively easy compared to SAML2 integration.


XSS only happens when data is output.

In your code sample you are setting the variable myhash to the hash value in the address bar. As your code doesn't contain any sinks and your variable is not output, the above code, in isolation, is not vulnerable.

However, to check for XSS vulnerabilities you need to focus on output to your application rather than input. Here application encompasses both the server-side and client-side.


New SSL cert implementation showing errors on Android only

We managed to solve this issue.  Our webserver is Tomcat and the fix was to follow the steps below:

Backup \repository\conf\tomcat\catalina-server.xml
Shutdown the Tomcat Server
Modify the catalina-server.xml file by changing the setting
clientAuth=want to clientAuth=false
Start the Tomcat Server.
Ensure the Tomcat server is started correctly.