What if IoT devices are fabricated with random passwords?

Getting rid of default passwords would be a start. But default passwords are not the only problem with these devices. Apart from this obvious problem we have undocumented accounts users cannot even change, backdoors which might be deliberately placed or just accidently left in for debugging, vulnerabilities against CSRF, XSS, DNS hijacking and much more.

A major reason for this mess are vendors which don't know much about security and don't really care and users which don't know and don't care either and also like to have the cheapest device possible. And as long as nobody causing this problem will be held accountable for this mess and will feel the harm they do to others it will not get better.

Making vendors feel the problem can actually be very effective. For example the influential german computer magazine c't did a lot of tests of routers in the last years and probably also thanks to their successful public shaming of vendors with insecure settings now probably most routers sold in Germany enforce changing of the access credentials on first use or don't use default passwords at all and also take care of various other security problems.


What do the security warnings from cflint mean?

It sounds like it's asking you to use parameterized SQL queries to prevent SQL injection. Using parameterized SQL prevents first order SQL injection attacks by treating the input as a parameter, rather than just concatenating strings.  For example, consider the following query :

  "Select * from dbo.Users where Lastname='{value}';"

Assume a malicious user is attempting to input "' or 1=1; --".  Using regular concatenation, this query becomes

  Select * from dbo.Users where Lastname='' or 1=1; --;

and the application will return all rows from the users table.  With parameterized SQL, the query will become

  Select * from dbo.Users where Lastname=''' or 1=1; --';

and will only return rows where the last name matches "' or 1=1; --".

This stack overflow post may also have some useful information.


Why can't a self-made SSL certificate have a fake signature?

Certificates use a digital signature algorithm, based on asymetric cryptography. So it involves a key pair (public/private).

The global idea is that the certificate has to be signed by someone (usualy a CA). Signing is a cryptographic operation that can be done if you know the private key. Verifying the signature can be done if you know the public key corresponding to the private one.

So when you get a certificat, there is a digital signature with it, and you're supposed to know already the public key of the CA (Global sign in your example).

The verifying process guarantees that the signing has been done by someone how know the private key corresponding to the public key you know.

A CA is not supposed to let anyone knows its private key.

So no one can fake a CA signature, unless he managed to get the private key.

To be more precise, signing is :

hash the certificate
encrypt the hash with the private key

Verifying is then

decrypt the signature
hash the certificate
compare the results

If results aren't the same it means either the signature is a fake (made without the private key) or the certificate information was modified after signing. The same results means the certificate is valid.


What is the best way to authenticate active directory users who wanna connect to Ubiquiti or Meraki's WiFi hotspots?

802.1X authentication has three parties: a supplicant, an authenticator, and an authentication server. The RADIUS (or its proposed successor Diameter) is used for the communication between an authenticator (e.g. a WiFi AP) and the authentication server. In this case, you are using Active Directory as the backend authentication server, and you need RADIUS for that. The AP (or the controller for your WiFi network) could also have an internal database and perform the authentication against it, but that's never the case with the Active Directory.

While some authentication methods available might also use e.g. LAPD queries for authentication directly against the Active Directory server, RADIUS has its advantages. One is the possibility to authenticate AD computer accounts instead of AD user accounts: This authentication doesn't involve saving passwords to the wireless network settings, and enables you to only allow Active Directory joined computers to access the network. With user based authentication you either allow practically all BYOD devices, or you are required to manually update a whitelist of allowed devices. With the help of Group Policy you can make all company computers connect to the correct WiFi network without any user actions at all. That profile can be forced to trust only certificates authenticated by a certain CA. This makes RADIUS the most advanced way to authenticate against the Active Directory.


Penetration Testing & TCP/IP Interview Question

This depends heavily on the firm and the role. Penetration testing is a varied field where expected knowledge ranges from running off the shelf tools and explaining the output through to manually crafting packets at the wire level. You also get firms that specialize in testing certain products and environments.

There are some jobs where you would be expected to know everything in exact detail. From the packet structure, field locations, congestion control mechanisms and possibly even implementation details from common implementations.

There are others where simply being able to state HTTP is over TCP/IP would be plenty. Someone specializing in in human factors may even only have basic user level computing skills. You might also just be one part of a team. Your skills might be in python frameworks and somebody else works on the lower levels.

I would suggest for any interview this knowledge can't hurt. Even if you specialize in something like content based browser exploitation it can still come in useful. But depending on the actual role it might not be required.


How can the german ChipTAN / CardTAN system be secure?

In my opinion a secure TAN has to be calculated from the receivers bank account number, the transfer amount, the Date/Time and a secret that is only known by the bank and the user.

From the Wikipedia article you refer to "The TAN generated is specific to the bank card as well as to the current transaction details. "

  But how can this all be calculated into 8 digits? In my opionion this is highly vulnerable to collision attacks.

Collision attacks only matter if you can do a brute force attack against the system asking for the TAN. I'm not sure about exactly this system but it is common to both limit the amount of queries from one system and also limit the number of tries in total. My guess is that you have only a single or a few tries to guess the TAN and if this fails you have to create a new TAN based on new transaction details (i.e. new time).

  If an attacker could catch multiple TANs and also knows the algorithm he can find a Key that can reproduce those TANs.

This argumentation is wrong. For example take a simple algorithm like sha256(secret + transaction_details): even if the secret is always the same and you know some transaction details and some output TAN's you will not be able to compute the secret with reasonable costs and time - i.e. reasonable meaning that the costs is lower than the gain and the secret has not been changed already after your computation is done. And, it is easy to harden the algorithm even more, just look at password hashes.


Pgp Private key storage on windows server advice

Generally speaking, it all depends on what you need to protect against and in what context: you need to explain first what you want to protect against and then design a sensible strategy for this: protecting against remote access is not the same as protecting against someone having access to the hardware. The running environment is important as well: you can't use a HSC the same way on a dedicated server located in your server room and on a VM rented from a public cloud.

Now, to be more specific: in case of server application, encryption is usually done in a way that will make it hard form someone who gained read addess to the data and source code of the application. This suppose that the operating system itself remains (more or less) secure and that the intruder doesn't get access to your running process (otherwise, he might as well just read the cleartext from memory).

For that, Windows offers a convenient way to protect data through the CryptProtectData and CryptUnprotectData APIs. These functions will allow you encrypt an arbitrary block of data using a key that is tied either to the logged on user account or to the local machine (you can add and additional key if you desire so although you will need to be able to store that externally somehow: it's of limited use if you have no secure storage available).

Doing the above is very easy and straightforward: that is basically how most of Windows stores secret data. Unfortunately, it has one major limitations: is of no use against any code that can run in the same context as your program. This means that it will be of no use in case of access to the physical machine or in case of any type of code injection flaw. Nevertheless, if you keep that in mind and if you deem that limitation acceptable, you can use these API to store the passphrases for your private keys.


Is there any reason in particular encryption keys aren't arbitrarily large?

Speed. While keys can be large, if they are too large you're algorithm will be so slow that it's not workable. Normally multiple key sizes are defined by NIST and their estimate until it will be feasable to crack these.

For instance AES-128 would take:

128-bit Key = (3.4 x 1038) / [(10.51 x 1012) x 31536000]
                = (0.323 x 1026)/31536000
                = 1.02 x 1018
                = 1 billion billion years

If you assume:

Every person on the planet owns 10 computers.
There are 7 billion people on the planet.
Each of these computers can test 1 billion key combinations per
second (and that's quite high).
On average, you can crack the key after testing 50% of the
possibilities.
Then the earth's population can crack one encryption key in
77,000,000,000,000,000,000,000,000 years!

So if you take a 2^100 you will not increase your security that much. Infinity is still infinity.

Your friend is not entirely wrong when it comes to requests of government agencies to weaken cryptography. Note that the U.S. still regards cryptography as a weapon. Since World War II, many governments, including the U.S. and its NATO allies, have regulated the export of cryptography for national security considerations, and, as late as 1992, cryptography was on the U.S. Munitions List as an Auxiliary Military Technology.

Recently it was discovered that RSA Laboratories was paid 10 million USD to cripple the random generation of one of their products:

  Documents leaked by former NSA contractor Edward Snowden show that the
  NSA created and promulgated a flawed formula for generating random
  numbers to create a "back door" in encryption products, the New York
  Times reported in September. Reuters later reported that RSA became
  the most important distributor of that formula by rolling it into a
  software tool called Bsafe that is used to enhance security in
  personal computers and many other products.

On the other hand they also increased security of DES back in the 70's by helping on the design of the S-boxes of DES. In the early 90's it was discovered that this significantly increased the difficulty of brute forcing DES keys. As Bruce Schneier said:

  So, how good is the NSA at cryptography? They're certainly better than
  the academic world. They have more mathematicians working on the
  problems, they've been working on them longer, and they have access to
  everything published in the academic world, while they don't have to
  make their own results public. But are they a year ahead of the state
  of the art? Five years? A decade? No one knows. It took the academic
  community two decades to figure out that the NSA "tweaks" actually
  improved the security of DES. This means that back in the '70s, the
  National Security Agency was two decades ahead of the state of the
  art.

References:

Mohit Arora,  eetimes, How secure is AES against brute force
attacks?
Joseph Menn, Reuters, Secret contract tied NSA and security industry
pioneer
Bruce Schneier, CNET, Saluting the data encryption legacy


How to get session info out of encrypted .NET viewstate?

Firstly, VIEWSTATE is a value to control the state of a view, it helps to keep data on view level and prevent Cross-Site Request Forgery (CSRF), in others words, this value is used to authenticate requests - sending data to backend and being sure is a legitimate request - , so it has the following features at least:

it's a secure pseudo-random value.
it's long.
it's unique for every view.

Maybe, you could decode this value, but it is just a pseudo-random value. Now, answering your question: yes, this value is secure, but it should be used to authenticate requests (prevent CSRF), but it shouldn't be used to authenticate users, because one of its feautures is to be unique for every view, then its life time is shorter than a session's life time, so don't confuse the purpose of VIEWSTATE with a session management.

I hope this information helps you.


Why are you using %00 at the end of your input? You're getting it "free" :) from the code itself in the . ".php" part

I'm guessing that the challenge is not in PHP7, since you can't terminate strings like that any more.

Anyway, using the payload ../etc/config (without null - %00) works for me:

However, maybe my setup is wrong:

  /opt/lampp/htdocs/project/files/test.php:

<?php
ini_set("include_path", ".:../etc/:../files/");

$filepath = "/opt/lampp/htdocs/project/files/";
$file = $_GET['page'];

echo("
 final path - ".$filepath . $file . '.php' . "
");
if (!file_exists($filepath . $file . '.php')) {
         echo "FAIL";
         exit();
}

include_once($filepath . $file . '.php');

  /opt/lampp/htdocs/project/etc/config.php:

<?php
echo "
WIN
";


Can the police track my phone even if I remove the SIM card?

It depends on the method you are being tracked.  If we are talking about a "wiretap," then the tracking is being done at the telco and as long as you maintain the same phone number, regardless of SIM or phone, it will get captured.  If we are talking about false mobile towers, like Stingray devices, then you are being tracked by multiple factors; SIM, phone number, IMEI, etc.


Multiple "Bearer" keywords in single Authorization header

Just because an application accepts multiple Bearer strings or maybe will work without any Bearer string does not make the application vulnerable. The Bearer string by itself neither adds nor reduces security, the relevant information are all contained in the JWT itself.
Sure, it might be that this behavior is connected to a specific implementation which then results in a vulnerability in another place, but acceptance of multiple or none Bearer by itself does not result in a problem.


2- For example HTTP Basic Auth is easily bypassable, is the same also for SSH Login, or this isn’t bypassable if you don’t know user and password?

Not sure why you mean it's bypassable. It certainly doesn't need to be. Assuming you are using a secure layer like HTTPS (so credentials aren't sent in the clear), a good implementation could be secure. Devices like ip cameras often don't have good and secure implementations, though, so it's wise not to expose them directly.

In contrast, ssh servers are generally very well implemented, and thus are unlikely to have vulnerabilities like those often found in those IoT devices.

With no vulnerabilities, the only way to log in would be to know (or successfully guess!) the user and password. Note that with SSH, you could disable passwords and connect using a ssh key (that's akin to using a client certificate with HTTPS, although not something I have seen any ip camera to support).

  1- To create SSH tunnel is necessary to open port 22 on router in which is connected the camera?

You will need to open the port the user connects to. SSH is often placed on port 22, but you could choose to place it at any other port number if so you wish.

Please note that you need a ssh server to connect to. The camera probably doesn't include that, so you may need another computer that you will proxy through, or perhaps you want to connect through the router, which need to be secure itself.

  If yes, is there risks by opening port 22?

You are exposing a system that wasn't previously exposed on the internet. In case someone got access to the system providing the ssh service, they would get more than if they just got access to the ip camera.

  Can hackers exploit?

It will depend if the implementation used has vulnerabilities that could be exploited.


Are there any known vulnerabilities in the official Gmail app for Android where opening an email (with no attachments) could infect the phone?

Are there any known instances of exploits/vulnerabilities in the official Gmail app for Android that could allow a malicious email to install unwanted software on the phone when the user opens the email?

Probably not publicly. Such an exploit would probably be fairly valuable, so either the discoverer would cash in on one of Google's bug bounties, or it's being used in secret. If one were ever publicly revealed, presumably Google would fix it.

  In particular: -the phone is configured to block installation of apps from third-party sources -no attachments are opened or downloaded

That will help protect people foolish enough to click a malicious link and then install an app they randomly received in an email. Against a proper exploit, such a setting is almost certainly irrelevant.

  What's the risk?

Probably about the same as can be expected from any comparable app published by a major and competent company.


What's the mathematical model behind the security claims of symmetric ciphers and digest algorithms?

I can't give you an answer that is going to leave you perfectly satisfied, because there is no such answer.  How do we know that our algorithms are secure?  Strictly speaking, we don't.  We have no proof that SHA256, or AES, or RSA are secure -- it is widely believed that they are secure, but I could not give you a mathematical proof of that fact, and who knows, it is always possible that widespread beliefs are wrong.

Our belief in the security of these algorithms comes from the fact that a lot of really smart, knowledgeable people have tried really hard to break these algorithms, without making much of a dent at all.  Of course, this is not a guarantee that no clever attack exists -- it is always possible there is some incredibly sneaky mathematical shortcut attack that no one has been clever enough to find, but the more people who try to find one and fail, the less likely that looks.  For practical purposes, it seems unlikely that a garden-variety attacker is going to discover an attack that dozens of really smart people tried to find and failed.

Your immediate reaction might be, what the heck?  Why are those cryptographers so lame?  Why can't they prove any of their algorithms secure?  Are they numbskulls?  The answer is, there are fundamental reasons that make it very difficult to prove that an encryption algorithm or a hash function is secure (except in special cases).  Roughly speaking, proving that an algorithm like AES or RSA or SHA256 is secure seems likely to be at least as hard as proving that P != NP (an infamously hard problem in computer science).  We have very few tools for proving that an algorithmic task can not be completed efficiently.  At its core, this is what makes it hard to prove that SAT cannot be solved in polynomial time (i.e., hard to prove that P != NP), and makes it hard to prove that there is no shortcut attack on AES (i.e., that AES cannot be broken).  So it's not just that cryptographers are lame, it is that we are up against very hard problems that no one knows how to make progress on.

Note that nothing I said above is specific to hash functions, or to symmetric-key cryptography.  It applies to all computationally-secure cryptography, including symmetric-key encryption, public-key encryption, digital signatures, hash functions, and many other standard primitives that we take for granted.

Your last question was: Can anyone teach me the theory of how symmetric-key algorithms are analyzed and cryptanalyzed?  How do cryptographers analyze them?  How do attacks work?  No, I cannot teach you this within the time and space constraints here.  There is an entire research field built up around these questions, with an intellectually deep literature on techniques for analysis of symmetric-key algorithms.  (See, e.g., the FSE, CRYPTO, and EUROCRYPT conferences.)  It takes years of dedicated study to learn this material.  Unfortunately, I cannot teach you all of that in the space available here.  The very short version is: cryptographers have developed a large suite of attack techniques, and as a starting point, any new primitive is first analyzed to see if any of those attacks will work.  If the primitive resists all of the known attack techniques, then cryptographers spend time trying to design ad-hoc or custom attacks against the primitive.  Cryptographers also study artificially-weakened versions of the primitive (e.g., with fewer rounds), to learn about the best attacks on those weakened versions in an attempt to extrapolate to the full thing.  If after many person-years of effort, no one is successful in attacking the scheme, then people start to gain more confidence.  More recently, there has also been some research on gaining confidence that the high-level structure is sound, or that all attacks of a particular class are guaranteed to fail, using ideas from the provable security community.

But at the end of the day, it is an art as much as a science.  Vetting a new primitive is extremely expensive: it takes person-decades of effort from intensely-talented specialists.  For this reason, smart users of cryptography generally try to use existing, vetted primitives, rather than inventing their own.  If you invent your own scheme, it is extremely unlikely you'll be able to arrange for as much analysis and vetting of your own scheme as the standard ones have already received -- so don't do that.  Don't "roll your own".  Instead, build on existing, standard, accepted primitives, like AES, SHA256, RSA, etc.


What difference to privacy will I get if i change my workplace wifi DNS to static ones on my iPad?

DNS just resolves the urls to ip adresses, If your workplace have a proxy on a gateway and encrypts\decrypts client requests with it's own certificate, then they will be able to monitor all your traffic. That is said, this is not a usual approach, since it would require a significant amount of money to install and maintain storage for all these logs. It is generally not a good idea to use internet access for a private means on any environment that may have require an installation of it's own certificates.


DNS spoofing+firewall port hijack/redirect to capture HTTPS requests without getting "certificate untrusted error" on the client browser

Certificates do not contain IP addresses, but in fact contain the hostname of the site they are issued to.  (i.e., www.google.com)

When a browser connects to an HTTPS site, it verifies several things:

That the hostname in the certificate (specifically, a hostname listed in the "Subject Alternative Name" field) matches the requested hostname.
The the certificate was issued by a trusted issuer (for example, a trusted Certificate Authority)
That the certificate has not expired, and it is past the issue date for the certificate.

In order to successfully (meaning no browser warnings) MITM HTTPS traffic you would need a certificate for the correct hostname signed by a certificate authority trusted by the client device.  Without this mechanism, HTTPS would not be effective at protecting against active attackers.  (Just how effective it actually is is a matter of debate among industry professionals.)

DNS plays essentially no role in certificate verification.  (There are some non-mainstream uses like RFC 4398, but I'm not aware of any browser using those.)


What is the full extent of information about my computer that a website can get?

There are a variety of ways your computer can be profiled from the browser.  The user agent presented by the browser gives some information.  Javascript can give you information such as time zone, screen resolution, languages, fonts, and browser addons. You can do similar things with flash.  These mechanisms are increasingly being used by advertisers to profile user and systems without using cookies (they are also to some extent used in some online anti-fraud systems).

The EFF have a good site and paper that profiles how unique your browser is and details their methodology.  https://panopticlick.eff.org/

I can't really answer the bittorrent question, as I have never investigated it.


Need to make secure apache while using cgi script in browser

we need to execute cgi scripts in browser.

Erm, no. CGI scripts execute on the server.

  In our case that user

You are using suexec for privilege seperation for a single user? That's really...unusual?

  In our case that user is ubuntu

Erk! And presumably this is an Ubuntu box. I guess you really must have a very good reason for doing this.

  The owner of [the document root] directory is also ubuntu

Oh dear. I don't think you've thought this through very well.

  if owner of project directories is not ubuntu then we can not write into these directories using cgi scripts.

You might want to spend some time reading the excellent documentation. You can write to these directories with other users (or have them owned by other users and accessible to reads (or reads) by your cgi-bin user.

As Steffen says, they likely got in using Shellshock, but once inside they had the run of your server. You can patch the shellshock vuln. but what you have described here is a catalog of bad design. If this attack was anything more than the most trivial of bots then the attackers will already have installed other backdoors.

Transforming what you have described here into something secure is going to take more than a few posts and answers on stack overflow sites.

As an absolute minimum:

Nuke your server from low orbit
Rebuild from a backup predating the attack (do not connect to internet)
Patch your server and work out a way of keeping it up to date
Install a host based IDS and learn how to use it
Seperate out the control channel for your content and run it in a captive portal
Use a uid other than ubuntu for executing your cgi scripts
Ensure this user only has write access where it absolutely needs it to do its job
Learn how to configure unix permissions, suexec and umask then come up with a better permissions model
For preference, run the webserver in an apparmor sandbox
Apply the model before you plug back into the internet


Is there vulnerabilities that are inherent to the concept of an open source antivirus?

I digress the notion that an open source antivirus database will necessarily be maintained by lots of capable people - this is not how open source works. The principles of open source would entice those that are not motivated by direct financial gain - whether these individuals are highly capable, or not - that is a question of chance or self motivation.

Also, there are two components at play - one is the antivirus engine itself, the second being the definitions database.

While I am certain that a couple of open source antivirus engines are adequate (e.g. ClamAV), maintaining an up-to-date database of virus signatures (and heuristics, for that matter), is a task that requires a vigorous vetting and testing process that would avoid false positives and risk making systems or software inoperable. Not that commercial antivirus vendors are immune to that problem - they are not, but I always look at efforts such as Wikipedia, where it works great to somewhat educate the general public, but it is questionable whether that model would work for an antivirus effort.

The Linux kernel, on the other side, is an open source effort that has had a great success in powering many critical systems. Whether that collaboration model can be used for an antivirus database, where the time from malware discovery to signature creation is critical, remains to be seen.

Overall, I am of the opinion that the idea of "people's" antivirus is good, but the implementation would be a major challenge - the signatures bit especially.


How does OpenVPN handle previously established connections?

OpenVPN creates a new interface for connections to go through, it doesn't override all connections that exist. In other words, it becomes an 'optional' connection. This can be important because you might need to use local network resources without the VPN.


Without being able to see everything that is happening, what other links like this do is to show you Google (or some other benign site), but in passing through other sites, they attempt to compromise your browser and system to install cryptominers or ransomware.
I'd suggest putting it through a malware analysis sandbox, like cuckoo.ee and see what it really does.
I put one of these links through VirusTotal and Cuckoo a couple of years ago to show the difference between a URL scan and sandbox analysis.


"Targeted" Brute-Force an Local App password

There's 2 quick options I can come up with from the top of my head, which are /usr/bin/expect (if this is available on mac), or Python's Pexpect library.

I don't know how expect does file IO, but for Python/Pexpect this obviously isn't a problem and you should be able to do what you're trying in 10-15 lines of code.


Does an image showing exception error on my site pose a prominent security risk?

You shouldn't show exceptions to users, and it does have a slight impact on security.

I'm assuming that you disabled exceptions, and are now worried about the data that is leaked via the screenshot:

Leaked Username

Usernames aren't generally considered sensitive information.

You may still want to keep it secret as defense in depth, to make some attacks such as bruteforce, phishing, or privilege escalation more difficult, but leaking a username is generally not considered a security issue.

Leaked absolute Paths

Full Path Disclosure may:

aid in the exploitation of LFI vulnerabilities. [Although an attacker may be able to exploit LFI without knowing the absolute path, or may guess the correct path themselves.]
provide information about the operating system. [This may help in discovering further vulnerabilities, or may aid in the exploitation of other existing vulnerabilities.]
leak system usernames. [see above.]
leak names of secret public directories and thus lead to disclosure of sensitive information. [although you shouldn't rely on the secrecy of a publicly accessibly directory to protect you; security through obscurity shouldn't be your main line of defense.]

Conclusion

On it's own, it is very unlikely that the leaked information can be used to start an attack. However, it may make other existing vulnerabilities slightly easier to exploit or aid in finding further vulnerabilities.

It is generally preferred to keep this information private, so you may want to change your username as well as the paths, but if it is not easily doable, the security of your server will not be severely impacted if you don't.


It is possible to do PUT and DELETE using Javascript with XMLHttpRequest. But in when using these methods for a cross-origin request preflight request will be done to check if the server is willing to accept this cross-origin PUT/DELETE. Unless the server explicitly allows this request the actual PUT/DELETE will not be done. For more information about CORS and preflight requests see http://www.html5rocks.com/en/tutorials/cors/.

Note that in (older) browsers which do not support CORS XMLHttpRequest is restricted by the same origin policy. This means that the browser will not even attempt to send a cross-origin request this way and thus no CSRF is possible.

In summary: unless your server is configured to accept cross origin requests CSRF with PUT or DELETE is not possible.


Does salt increase security if there is only a single hashed password?

Absolutely.  If no salt is used, then a precalculated set of tables, called rainbow table, can be used to determine the plaintext of the password.  With salt, a brute force process of calculating every possible value till the hash is matched is the only way to find the password.


How can I use Message-ID in header to screen (filter) Emails?

Yes, most email clients support this capability. I use Thunderbird but Outlook can do it as well. I haven't touched Outlook in awhile, but it's something like this:

"File" tab in the main menu
    "Manage Rules and Alerts"
       "New Rule"
           "Select a template" from the Rules Wizard dialog window.

Once you get into it, it should be pretty clear.

Yes you can filter on any header. I used to set a filter at work on a header of "PHISH" to flag corporate phishing test emails.


How to limit the need to type a long master passphrase to only once per login session?

You've limited yourself quite a bit to only KeepassX and pass, but you can keep KeepassX open all day long and set it to not lock.  Then you only need to unlock it when you login, but won't need to unlock it again.  This is essentially what ssh-agent does for ssh keys (keeping credentials in-memory after unlocking once).


Must mail relays always indicate the use of encryption in the “Received:” header field?

I’m wondering if this is always the case (e.g., because it is required by some sort of standard).

Not really. The most recent RFC for SMTP RFC 5321 describes the format of the received header but this includes no such information, probably also because STARTTLS for SMTP is an extra standard. This standard is described in RFC 3207 and provides no information about what should be added to the Received header either.

Generally the information are stored inside comment parts of the Received header (which can be inserted almost anywhere) and seem to adhere to not a single specific format. Thus it is mostly up to the mail server if and how this is included in the Received header and different mail servers handle it differently.

Apart from that it is no proof that the message was really transmitted with TLS even if you find this header. This header is just inserted by the server which can put anything inside it. It could also be modified or removed by other mail servers further in the path. None if the information there can be trusted fully, because they are not protected against deletion, spoofing or modification in any way.


SSL: How to send generated client certificate from server to avoid MITM?

You have two potential attacks:

The attacker poses as a fake server, and talks to the genuine client, feeding him a wrong certificate or other nefarious data.
The attacker poses as a fake client, and talks to the genuine server, obtaining a valid certificate with the genuine client's name but the attacker's key in it.

A man-in-the-middle attack is when the attacker does both simultaneously. However, each attack is problematic in its own right.

Defeating the first attack (impersonation of the server), use the standard mechanisms: have the server use a certificate, issued by a well-known CA, that the client trusts. All HTTPS Web sites do that. This is how, when you connect to https://www.paypal.com, you get the nifty padlock icon and know that you are really talking to Paypal's server.

To defeat the second attack, well, it is up to you: the server is creating and sending a certificate to "a client who just connected". How does the server know what to put in the certificate ? From where comes its knowledge of the client's identity ? If, for instance, the "genuine client" is authenticated by virtue of having been granted a one-time registration password, then the communication will occur within a HTTPS connection. In that connection (where the server is verified as "true" by the client, see above), the client sends its one-time registration password, and the server, from that point onwards, knows that it is talking to the expected client, and can send him a certificate or whatever it wishes to send him.


Does Linux support the NX-bit on ARM processors?

The NX-bit implementation its supported since ARMv6, and yes, linux also has support for it. (NX implementations needs both OS support and CPU support)

Now if you want to check the nx bit, you can do it like with any other platform, there's a good old script called checksec.sh from the trapkit team, here you can see the implementation:

  # check for NX support
  if readelf -W -l $1 2>/dev/null | grep 'GNU_STACK' | grep -q 'RWE'; then
    echo -n -e '\033[31mNX disabled\033[m   '
  else
    echo -n -e '\033[32mNX enabled \033[m   '
  fi

Full script: http://www.trapkit.de/tools/checksec.html

If you want to see a implementation in python, Peda (Python Exploit Development Assistance for GDB) also has one (they ported the trapkit script)

https://github.com/longld/peda/blob/master/peda.py#L2543


Is it possible to War Drive for specific Bluetooth devices? What is the range?

Well bluetooth scanner apps do exist (e.g. like this one ), so if the lock is broadcasting it will likely be discoverable.

As to range, as @adnan says in comments depends on the class, however there have been examples  of specialist antennas picking up signals over a mile away.


What is the current EU standard for data destruction?

I'm not 100% sure what the EU laws and guidelines would be however; I suspect it's left to the member states to decide what to issue in regards to deletion of personal information. with that said I found a PDF from the UKs Information commissioner’s Office (ICO) and they state in this document that...

  ...the ICO will adopt a realistic approach in terms of recognising that deleting information from a system is not always a straightforward matter and that it is possible to put information ‘beyond use’, and for data protection compliance issues to be ‘suspended’ provided certain safeguards are in place

  information has been deleted with no intention on the part of the data controller to use or access this again, but which may
  still exist in the electronic ether. For example, it could be waiting to be over-written with other data.

  information that should have been deleted but is in fact still held on a live  system because, for technical reasons, it is not possible to delete this information without also deleting other information held in the same batch.

and in addtion to this in the next section it states.

  The ICO will be satisfied that information has been ‘put beyond use’
  if not actually deleted, provided that the data controller holding it:

  is not able, or will not attempt, to use the personal data to inform any decision in respect of any individual or in a manner that affects the individual in any way;
  does not give any other organisation access to the personal
  data;
  surrounds the personal data with appropriate technical and
  organisational security; and
  commits to permanent deletion of the information if, or when, this becomes possible.

So I suspect that they, themselves do not know the best approach so are leaving it vague. As long as you make the effort to show you deleted it and tried to make it un recoverable then I guess they are happy with that. As you and Graham Hill (comments) suggested, I would go with an industry standard such as BS EN:15713 or DIN 66399.

Accessed 15 May 2016

ICO Website for newest guidelines (UK)

ICO PDF on deletion


How to get medical vendors to take security seriously?

I'm doubtful this is something the infosec community can change.  Healthcare is too specialized and the devices are typically proprietary closed black boxes.  You could develop a set of security standards and hold every vendor to those standards.  Those that fail the audit would be subject to replacement (see below).  There are lots of variations of security guidelines available, but honestly, the key to success is going to be strength in numbers... and dollars.
Companies that produce these "weak" products, like all other companies, work for money.  The best way to "encourage" better behavior is to hit them where it hurts... the wallet.
If you really want to enact change, and I certainly hope you can, get several large hospitals to ban together and tie your purchases and renewals to specific changes in the products you're buying.  Sure, GE and Phillips are monsters in comparison, but while companies treasure these super large customers, they can't depend only on them.  If only one of them decided to change vendors, it would hurt too much (ie. all eggs in a couple of baskets).  They still need other large and medium sized customers to balance out their revenue streams.
I work for a large software company and I have seen first-hand the impact a large angry customer can have on exactly what kinds of efforts we place in product development.  When more than one large customer pushes hard for the same feature, bug fix, whatever, the sales team beats up on the product development team and the improvements get made... fast.
Now, if you're like most large customers, you can't simply refuse to buy a key component of your business... say patient telemetry machines... because you have to have them.  But, chances are, you keep buying the same machines from the same company... I mean, most do because it's much easier to support a homogeneous environment.  So, let your vendors of these key devices know that after this purchase you will be looking to replace your entire estate of "telemetry machines" because of security concerns.  That will get their attention.
Some products are what we call "sticky".  That means that once a customer has implemented a solution, it's hard to get rid of... and the vendors of these products know it and will start to take customers for granted.  Tell the vendors of these sticky devices that you're putting out an RFP to their competitors.  Talk about a scramble!  Now, imagine several large customers all telling a particular vendor the same thing.
Also, for products that require licensing & maintenance renewals... tie the renewals and new license purchases to specific feature requests and security enhancements.  ie. Make it part of the renewal contract that the vendor will implement A..B..and C within 12 months (or whatever).  That way, they are contractually obligated to make the changes.  You don't even have to threaten them if they don't meet the goal.  At that point it's a breech of contract scenario and let the lawyers deal with it.
If you can get more large hospitals to demand the same things, the power of your request will be magnified significantly.


Is it useful to protect hashed password with encryption?

What's the threat model? It could be of benefit to protect the password storage with an application-side secret, but only if you think it's a realistic scenario that your database is going to get compromised—without your application server, which holds the secret, also having been compromised.

Usually, the application layer is considered the more vulnerable part and the database layer more protected, and for this reason it is not considered useful to protect the data with an application-side secret. But that may not be the case for every app, and personally I would somewhat question this assumption given the prevalence of SQL injection.

The downside of introducing an app-side secret is that you now have to worry about key management processes. What's your mechanism for replacing the key if it gets compromised? Are you going to rotate it as a matter of course? How is your key stored so that you can move servers and not lose it (potentially making all your data useless)? For short-lived keys (used for eg signing session tokens) you may not care but for long-term password storage it becomes important.

The further downside with symmetric ciphers (especially block ciphers) is implementing them correctly. Since you are hashing and don't need recoverability, you could instead include the secret in the hash (as a ‘pepper’)... but then you wouldn't be able to re-hash all the password data on a key change, so you'd have to have a multi-key method for rollover.

ETA re comment @Pacerier:

Hashing does not prevent an offline guessing attack by someone who has obtained the password database. It only increases the amount of time it takes for that attack to bear fruit; with a hashing scheme of appropriate difficulty (ie rounds of key derivation rather than raw salt length per se), it will hopefully increase that amount of time to long enough for you to notice you've been hacked and change everyone's passwords before too many of their accounts are lost.

Protecting the content with a secret key (either using encryption or including the secret key in the hashed material) does prevent the offline guessing attack, but only as long as the secret key itself is not leaked. If the secret key is on the app server separate from the database server, the passwords are only attackable if both machines are compromised.

How much of a benefit that is arguable, given that many kinds of attack can end up compromising both, especially if the app server and database server are the same machine. There also is a price to pay in manageability as discussed. So whether there is net benefit needs to be judged on a case-by-case basis with reference to the threat model.


Where can I find all SSL CA certificates

It seems there is no single source to get all the keys. But looking at your requirements, starting with a credible browser's certificate database could be a good way to approach. The link you mentioned seems to be a good source. This perl script can download the certificates from the site and converts them from txt to PEM format.


ECC based Client Certificate import in Chrome/Mozilla in windows

I have spent some time this morning to make some experiments on Firefox (version 26, for MacOS X), Safari (6.1.1, for MacOS X 10.7.5) and Chrome (31.0.1650.63, for MacOS X 10.7.5). Chrome and Safari both rely on MacOS's support for X.509 certificates, which is managed through KeyChain.

All my tests use EC keys from the P-256 curve, which (in the certificates) uses the "named curve" encoding. All certificates were generated with OpenSSL and match what you show. In particular, the extensions in your certificate are fine and work flawlessly in a RSA-based certificate.

What does not work

KeyChain refuses the import of any certificate which features an ECDSA public key; it returns an error "-67712" which maps to errSecInvalidKeyRef, aka "An invalid key was encountered.". See this reference page. Interestingly, KeyChain is supposed to be aware of the existence of ECDSA Keys since MacOS X 10.7, but this seems not to have percolated into full support for X.509 certificates containing ECDSA keys or signed with ECDSA.

Firefox uses its own cryptographic code called NSS. This includes X.509 support. Support for elliptic curve cryptography is new in NSS, and, more importantly, it is optional, so its presence depends on whether it was activated or not at build time. These messages indicate that at least RedHat still builds Firefox/NSS without ECC support.

In my tests, Firefox (the MacOS X version, obtained from the official source) accepts to try to import certificates with ECC, but with mixed results. A certificate signed with ECDSA will be somewhat broken; Firefox's GUI, when displaying the certificate, will claim that the certificate "cannot be verified for unknown reasons". Firefox will fail on the following:

Validating a server's certificate which has been signed with ECDSA.
Using a client's certificate which has been signed with ECDSA.
Using a client's certificate which contains an ECDSA key.

What works

Firefox, Safari and Chrome appear to be happy to connect to a SSL server whose private key is of ECDSA type. All three seem to require that the certificate has been signed with RSA (haven't tried for DSA), though. So the server itself may use elliptic curves and the cipher suite can be ECDHE-ECDSA-AES128-GCM-SHA256 (that's what Chrome used in that case), meaning that the key exchange was an elliptic curve based Diffie-Hellman, and the server half of that ECDH key exchange was signed by the server with its ECDSA private key. Chrome used TLS 1.2 (good !); Safari still uses TLS 1.0 (less good, but not too bad).

Replacing SHA-1 with SHA-256 or back changes nothing to all of this, so SHA-256 support seems, at last, to have reached completion.

OpenSSL supports EC keys in certificates, for certificate signatures, and for client and servers with no problem. In my tests, the server was OpenSSL with the s_server command-line option. openssl s_client connects to my server without any issue and can use an EC-based client certificate.

What might work

A custom build of Firefox with ECC support fully activated in NSS might work better. In any case, first try the P-256 curve (as you do) because most software that claim to "support ECC" actually support only two curves, P-256 and P-384 (because of the so-called "NSA Suite B cryptography"). Support for the 13 other NIST curves (from FIPS 186-4) is much more confidential; support for "generic curves" is a rarity (I never observed it in the wild).

Recent versions of Internet Explorer are supposed to be aware of ECDSA. Note that Windows has two internal frameworks for cryptography, CryptoAPI (the old one) and CNG. Only CNG supports EC keys, or, for that matter, SHA-256. CNG appears in Windows Server 2008 and Windows 7; up-to-date IE on these Windows versions should be able to use both certificates containing EC keys and certificates signed with ECDSA, both for client and server. At least so claims the documentation. Don't trust it until you have tested it, though.

Chrome on Windows will rely on Windows' abilities for X.509 certificates, so it is plausible that Chrome on Windows 7+ would be on par with IE's abilities on the same platform. There again, tests should be performed.


How does iOS prevent unauthorised code from running?

Once a computer boots, the operating system is given near exclusive control over the system resources (kernel access).  After this occurs, if a program wants to run, it must ask the OS to let it run.  Before iOS allows an application to run, it examines the code that is going to be loaded in to memory from the binary and checks it against a signed value that proves to the OS that Apple has reviewed the contents of the binary and given it the green light.  Only after this check succeeds is the code allowed to run.

Jailbreaking removes this check by altering the OS such that it sees all applications as valid and allows them to run.  Since Apple won't sign an application that makes these changes, exploits have to be used in high privilege signed code (normally the OS itself) to allow the needed changes to be injected in to the system.

The same exact kind of security could be implemented on other devices as well (in fact, it is optionally able to be turned on in Android) however, not having the option to turn it off is highly contentious as at that point you don't really own your own hardware anymore since someone else is telling you what you can and can't do with it.  It is good for preventing people from accidentally installing bad things, but bad from a user freedom perspective (which is the main reason we haven't seen this technology expand in to desktops despite the fact it is completely technically possible to do so.)


I receive spam despite a captcha, has my wordpress blog been hacked?

Posting spam doesn't require hacking in any ways.

Regarding the captcha, there is two possibilities:

Either the captcha is automatable (I don't know for your website, but I still encounter a lot of websites bearing completely useless captchas).
If the captcha is not automatable, then spammers can hire people to solve them for as low as $2 for a thousand captchas.

Your website is usually not specially targeted: they just target any random URL where comments are directly published. When possible, prefer to avoid automatically publishing visitors comments but publish them after moderation, at least ensure that the rel="nofollow" property is used for links in comments so spammers websites doesn't gain any reputation by posting links in your comments section.


How can I conduct penetration testing on VirtualBox

On the VM settings, set each of the NICs to Internal Network.  This will allow the VMs to communicate with each other but not the outside world.

As to getting started, get a premade .ova of Kali and another of Metasploitable.  If you happen to have access to a Windows Vista or earlier disk (especially if it doesn't ship with any service packs!), install one of those, too.

This will allow you to launch attacks and scans from Kali without accidentally hitting your real network.  Plus, metasploitable is designed to have vulnerabilities, so you're not hitting a proverbial brick wall before you know how to use the hammer.

In particular, in Kali, look at nmap (especially with the --script option) and metasploit.

I noticed you're asking about network penetration, too.  Consider that an additional complication for later, as firewalls are another obstacle entirely, and except where you've enabled port forwarding, you're relying on the targets to reach out (or making them reach out after some compromise they've brought upon themselves; still, not the same as port scans unless you already know which ports you purposely make vulnerable, or are looking for vulnerabilities in the router.)


Can the data transfered from a PC to Dropbox or a USB drive be logged and detected?

If you are using a computer provided by, controlled by or just even accessed by your employer (as almost everybody does at work), then the answer is yes, your employer could potentially log what you are doing.

When they have full control over your computer there is no limit to what they could log - screenshots, keystrokes, network traffic, etc, etc - and there is no reasonable way for you to find out.

However, if you are not working with something sensitive surrounded by high security, it might be unlikely that your employer has gone through the effort to log these things. What they are most likely to have is perhaps logs of your network traffic, e.g. your HTTP requests (but probably not bodys since they take a lot of space). In these filenames of files uploaded to dropbox might be found. (And yes, even if you used HTTPS your employer could get around that with an installed root certificate.)

So the answer is possibly, but you can not know for sure.


Is downloading a PDF from a browser-based app locally a HIPAA issue?

I asked a somewhat related question a while back, and after add'l research, I think I have an answer for you.

Short answer is Yes, it's a HIPAA issue.  However, it is not implicitly a HIPAA violation.  I'll assume that since you're discussing CPOE from the system in question, we're taking an provider organization's workstation, or a provider's workstation.  In either case, onus is on the workstation owner to have implemented proper security measures and practices to protect this information as it has been left on the machine.

1) The cache/download folder should be able to be cleaned quickly and implicitly via any "cancel"/abort action baked into the UI workflow, leaving no trace of PII/PHI. (If you've launched acrobat and it triggers a download to your download folder, I'm assuming we're at the point where the user has said "generate this".  Care providers may not like a pop-up every time that reminds them of the HIPAA considerations, however the 'do not show this message anymore' pattern should suffice.

2) Smart configuration of system (e.g. windows) authentication can protect the signed-in user's file structure (including the cache/download folder).  If nobody else can get to this data without authenticating, it's potentially okay.

3) Most responsible organizations dealing with HIPAA compliance have strict auto-logout procedures (e.g. 10 mins), however walking away w/o logging out and leaving Acrobat open as you describe is not a good move (so don't burden users with this liability in your product design).  This should be part of a more comprehensive, published, and frequently maintained security framework for the organization's HIPAA compliance.

4) The data/disk had better be encrypted in case the workstation gets into the wrong hands.

Bottom line is, pretty much any application which offers 'print' capability can introduce the workflow you're asking about.  As such, this in and of itself is not a HIPAA violation.

My related question had to do with an assumedly different scenario, where I was inquiring about providing a patient with a copy of clinical documentation.  The answers here basically confirmed that as long as you're explicitly stating the handoff of ownership of this data to the end-user (who's assumedly logged in to be granted access to the document in the first place), you needn't password-protect, encrypt, etc., the document itself.

Hope this helps.  Also browse the other HIPAA-tagged items here, as there's lots of discussion about transmission, storage, etc.!


How to fix specific XSS issues in URL via php?

I suggest you read about defending against XSS.  OWASP has good resources.  You need to apply proper input validation to all input values, and properly escape all dynamic values that you insert into the output HTML document.  There are many online resources on how to prevent XSS.

As far as your specific application, you haven't provided us enough information to diagnose the issue.  Did you try opening my_php_file.php?nsextt="..." in your browser, to see what happens?  Does an alert dialog pop up?  If you view the source of the response, do you see a "style=..." attribute anywhere in the response?  Also, though you say you don't use any GET parameters in my_php_file.php, is it possible that code in my_php_file.php might include another PHP file or might call some other function that produces unsafe output?  I suspect you may have an XSS vulnerability that allows injection of a new attribute into the middle of some attribute list somewhere.

You mention the approach you are using to sanitize the parameters on other pages.  I'd like to mention that this is not the proper input sanitization method.  strip_tags does not prevent XSS (strip_tags is not guaranteed to remove all tags; and even if it did, removing all tags is not sufficient, as one can still mount an XSS attack by injecting attributes without injecting any new tags).  A good rule of thumb is that if you're using strip_tags, you're probably doing something wrong.

More generally, input validation is not about blindly throwing every stripping function you can think of the data.  Instead, you should check that the input matches a suitable whitelist or regexp, as appropriate for the type of the data.   And, when you output the data, you should escape it  in a way that is suitable for the context where the data will be inserted.  For instance, if you are inserting it into the standard between-tag HTML context, you can escape the data with htmlescapechars.  If you are inserting it as a link (as the value of a href attribute), then you need to ensure that it is a properly formatted URL with a safe scheme (http or https are safe; javascript is not).  There's a lot more to say about input validation and output escaping: see the OWASP resources for a lot of great information on this topic.


It isnt normal that your are experiencing DDOS attacks. Try using Wireshark or another network sniffing tool to look for Botnet traffic. IF you boot Wireshark and use the filter

  dns.flags.rcode == 3

If Wireshark is returning a lot of failures a good bet would be to set up a IDS such as Snort and create a rule to block the specific traffic.

However different botnets use different ports so this is not a sure bet. Unfortunately there is no "find all" button on Wireshark but this is a good start.

Check out HoneyNet for further info on the subject of capturing the Botnet traffic.

EDIT: Snort: https://www.snort.org/
      Wireshark: https://wireshark.org/


"from a LAN device (raspberry pi) located inside my company"

Depending on how strict your company or any company is, LAN connections to the Companies infrastructure should not be that easy. Some companies automatically block ports on employees desks, only when needed then its opened by the sysadmins.

"using OpenVPN to connect my Raspberry Pi to the outside through a virtual machine" ....
"Just to avoid any problem with the IT, I am not using the standard 1194 port, but a more standard one : 443."

Again, it varies from companies to companies on how strict their outbound connections are. Just so happens these connections was allowed & just so happen that you were on a network that allows internet access hence 443 being up. They can't just block that, you were able to go out because they allowed you to go out!
To determine the security posture of a company stems from its purpose of its different segment of networks, internet-facing networks, intranets etc.
There's a reason why there are these measures in place, the company placed a certain level of trust on you. You see anything wrong here?

"As devices accessible from outside must be placed in the DMZ, I couldn't get a proper authorization to do this. In fact, it is too complex and it requires too many approvals. So, because I am lazy, I am just using..."

Employees are the weakest link in any company and you've just proved that.


CSRF Security Independent From Front-End

Yes, one method of ensuring CSRF protection is to check the Origin and Referrer headers to see whether they match the expected origin, as these headers cannot be overwritten by any frontend code. However, the origin header is only sent on POST or CORS requests, and the browser implementations of these headers have historically not been consistent; e.g. possibly allowing JavaScript to spoof one or more of the headers (modern browsers should behave correctly, although I cannot speak for the future spec or implementation).
This protection only requires implementing a server-side check on every POST request. It is important to deny the request if the sent origin doesn't match, or if none was sent at all.
The OWASP CSRF Cheat Sheet includes some reasons for why you may not want to use this method exclusively. However, if you face none of those restrictions, I personally feel that this method is okay to use in lieu of a more complex method.
Also depending on browser support is the "SameSite: strict" cookie option. This prevents cookies from being sent at all from a 3rd party site, also mitigating CSRF.


The quote is short, but I think the author is trying to say that the router wasn't about ATM skimming, and not even about the ATM itself. It was a MITM for customers who used WiFi (personal devices).

In this case, it was just a rogue AP that presented a fake certificate to users, and the users (or their poorly written apps) had to accept the fake certificate.


How secure is EncFS compared to TrueCrypt?

When we're talking about security, we're talking about security of the data. In this case it's really not just the encryption algorithms that need considering but the implementation of it and the software used.

There are examples of when poorly implemented crypto technology meant that significant information could be gained about the data 'encrypted' or even the original data itself. The main example is usually SSL where no certificate validation is performed, meaning breaking it is a simple matter of intercepting certificate exchange and injecting your own.

What you need to ask yourself is how well vetted the software implementing the encryption is. Arguably TrueCrypt is the more mature solution, as well as currenlty undergoing a public auditing sponsored by some big infosec companies: http://istruecryptauditedyet.com . These audits are performed because you really don't know if anywhere along the encryption implementation has a weak-point. It only takes a single chink in the chain to expose sensitive data.

For this reason, I'd side with TrueCrypt being 'more secure' than EncFS - but the reality is they could be both just as secure. Without reviewing the source code, which is a big task, you can't always tell.


How to send emails with Thunderbird without revealing my internal and external IP address?

Including the originating IP was standard practice until relatively recently. A number of WEB mail providers that also support IMAP/POP clients like Thunderbird have altered their handling to process client email as virtual web mail, replacing the originating IP with that of the Web server. As of 10 minutes ago, that does not seem to be the case with Gmail, it still includes the originating IP.
There are other email providers that don't do this. Since this is of interest to you, I'll remind you that Gmail clearly states that they scan your email content, in case you care.
Using a VPN will indeed show only the VPN IP and not yours. However you may run into problems with Google Security objecting to the VPN IP, particularly if it's from another country. It's easy enough to try, go ahead and test it.
As for recipient providers, I suspect some will blacklist/block/flag the VPN and some won't.
If this is a significant enough concern for you, I'd suggest changing providers.


No. The phone company simply refuses to send you that number.

The police can detect hidden callers though, because the phone company doesn't hide numbers from them. 911 phone lines are fundamentally different from ordinary lines. They even get mobile phone locations, not just the numbers.


Why can't mail clients verify an email was sent from the user and server it claims to be from?

Well, its not that easy.
Almost all SMTP servers are configured to prioritise the delivery of emails. This makes for example encryption between servers opportunistic today. Another problem is, how can you know for certain that a specific mail server is the only one allowed to send emails for a specific domain? Also a email almost always pass through many servers before reaching its destination. This is only a few of the problems we are facing.
Possible solutions
There are several solutions to this problem that are widely used at the moment. But I think the biggest problems are adoption and ease of configuration.
Here is a few:

DKIM and DMARC - the server signs sent emails with a asymmetric key, where the public key is published in DNS, this way the receiving server can verify the authenticity of that email.
SPF - You add DNS records that tell what servers are allowed to send emails for a specific domain. This way (if the receiving end honours it) emails from a domain will only be accepted from a defined set of servers.
S/MIME - the USER signs the email with a x509-certificate from a trusted CA, this way you can be reasonably sure that the email was sent from the person you think it was.
PGP signing of emails

The problem I guess is that solution 1-2 is hard to setup for administrators (and voluntary) and solution 3-4 is even harder to setup for the user.
Your solution would require new protocols implemented in the email client and would take a very long time to see widespread adoption.


Stretching a hash, many iterations versus longer input string

The main reason why concatenating the salt and password many times is not used is a combination of tradition and laziness. Namely, since password size is not fixed, the number of copies would have to be adjusted so that the "much longer string" size reaches a given goal. It seems that some initial implementers of such schemes found it cumbersome, possibly because it implies using a "streamed" hash function implementation (which accepts data by successive chunks) instead of a one-function-call implementation. Most ulterior designers simply copied the previous designs for no real good (neither bad) reason.

On a theoretical point of view, multiple concatenations of the salt and password are better, because multiple iterations reduce the space of possible hash values (a hash function is not a permutation). But the reduction does not go below a 2128 space of a 256-bit hash function, so no worry here.


PDF.js has been developed in javascript and is inside the (very secure) js sandbox. Chrome has one of the most secure js sandboxes, so you might want pdf.js in chrome.

Evince is very easily exploitable. I don't know which part the fuzz-testing included, but Evince bases on poppler, so that may make Okular insecure, too.


Can malicious sites use session data from iframes?

No. A malicious site cannot interact with its iframes which point to other domains. It can only issue GET and POST requests without reading the corresponding responses, like any other web page opened in the same browser. A feasible attack would instead be clickjacking.

This question is a possible duplicate of the question Javascript and same origin iframes.


Trying to dictionary attack my own gmail account with hydra on smtp

What you are doing is a violation of the Gmail Terms of Service. Applicable text:

  Don’t misuse our Services. For example, don’t interfere with our Services or try to access them using a method other than the interface and the instructions that we provide. You may use our Services only as permitted by law, including applicable export and re-export control laws and regulations. We may suspend or stop providing our Services to you if you do not comply with our terms or policies or if we are investigating suspected misconduct.

You aren't hacking "your own account." In this case, you are attempting to bypass GMail's authentication system, a service which most assuredly does not belong to you. This is at best a ToS violation and at worst illegal.


What is the point of AES key wrap (with JSON Web Encryption)?

If you need to store a large amount of data, the advantage of wrapping the key within an encryption layer means that if you needed to change the key at a later time then you would not have to reencrypt all your data. You simply change the KEK (Key Encrypting Key) and reencrypt the CEK without having to transfer all the ciphertext again.

For example, say you were using JSON in order to transmit data to your server for safe storage. You could transmit all this data using A256KW and your server at the other end simply stores this.

That is, the following is transferred and then stored server-side:

Encrypted key (CEK):  66xZoxFI18zfvLMO6WU1zzqqX1tT8xu_qZzMQyPcfVuajPNkOJUXQA
                 IV:  X5ZL8yaOektXmfny
         Ciphertext:  brz-Lg
 Authentication Tag:  xG-EvM-9hrw0XRiuRW7HrA

If you needed to change the key you could simply pull the CEK to the client, decrypt with the old KEK and encrypt the CEK with the new key and then send it back to the server to update all relevant records.

For short-term transmission purposes only, this is not important and it would be easier to use Direct for a smaller payload.


Is amazon S3 secure enough to hold personal documents?

From a purely technical perspective, if you encrypt it properly before you upload it, and it stays encrypted all the time it is in the cloud, then the data is very safe.

However, there are very probably extra levels of legal compliance you need to meet. This is "Personally Identifiable Information" and there are a lot of laws and regulations that apply to handling it. You need to take legal advice on what you need to do.

Note that you not only need to worry about the jurisdiction where your client is, but also the jurisdictions where the data is, and the jurisdictions where the users are. (That alone might make using S3 more of a challenge, since you'll have no way of controlling whether the data you put in there is in stored in Newark or Tokyo or some other place Amazon hasn't even told us about yet.)


Is it safe to use OAuth (Resource Owner Password Credentials Grant) for authentication?

The biggest security issue associated with Resource Owner Password Credentials Grant is that the application/client is privy to the user's password.

For instance, if the application/client was from a company AwesomeACME, and the Identity Provider was Google, I certainly wouldn't want AwesomeACME application/client to know my Google password.

However, if AwesomeACME also happens to be the IdP, I would be less concerned but would still question why they didn't use Authorization Code Grant instead.


Per PCI-DSS Req. 3.3 You are allowed to display at most the first 6 and last 4.

This is typically not needed (most software just use the last 4).

I've seen a lot of app companies take the stance that they need the PAN digits to find transactions, however, this is usually because the of the poor implementation of the software and most of the industry has moved on to providing tokens.

It's not really a security thing other than to check that the full PAN is not stored anywhere.

Note:

Some states/cities have recipient requirements requiring "4 and 4" or "6 and 4",  or only 4. E.G New York


Mixing green (EV) ssl certificate with non EV certificate

This should not affect the EV status displayed in the browser's address bar.  The EV status is based only on the certificate presented for the page itself.  (You will, of course, not have EV displayed if you have mixed content or invalid certificates presented, but using a cheaper cert on images.yourdomain.tld should not be a problem.)


Does it pose a possible vulnerability to publicly expose login username and server name in a public Github repo?

You are not being paranoid. Getting internal information like usernames and passwords are part of information gathering which is done before breaking into systems. And especially with usernames and passwords it is common (but not recommended) to use the same or similar names and passwords to protect other resources, so these are valuable information.

But apart from that it is hard to take such published information back. The information are still in the git repository, even if they are not in the current HEAD. So you should at least make sure that none of these information or variations of these are in use on any of your systems.


Are there any consequences of clicking on a URL to a facebook.com link?

In theory, you could have caught a drive by download. However, it is much more likely that you have been redirected to an advertisement page and the respective owner now rejoices about the revenue of all the sheeps clicking on funny looking links ;-)

You can delete your cookies to get rid of any tracking/advertisement ones and I generally recommend installing a third party script, frame and cookie blocker. Also I hope you are not browsing with an administrator account.


Configuring Argon2id for Multiple Threads

There is no perfect solution. There is always a trade off between security, price and user experience. If you want to get both higher security and acceptable response times, consider using more hardware resources (higher price).

First estimate the risks to decide what security level you actually need. What are exactly the threats? What benefits can an attacker get in case of successful brute-forcing of single password? What will it costs for the attacker to brute-force a single password? Are the possible benefits and the costs commensurate? Does it make sense for the hacker at all? What can be costs to you and to your users to provide particular level of security? E.g. if you reduce the number of requests per server/container from 500 to 100 (to enable more hashing iterations) and increase the number of servers/containers x5, will be the price x5 acceptable to you?

Also we should distinguish two basic use cases.

There is a single user. For instance, a user on a laptop uses hash (derivated password) as a master password in password manager, or to encrypt/decrypt a drive.
Then it makes sense for a single hash to use as much resources as possible.
There are multiple simultaneous requests, for instance in some web application. If some requests require too much resources, other requests (normal requests that don't use password) will notice degraded performance.

The number of threads: The main purpose of this parameter is to load memory bus as much as possible. But normal CPUs have only 2 memory channels, where as many graphic cards have 6 or 8. Thus, exhausting your server you don't exhaust the resources of the attacker. Means, it does not necessarily increases your security. That's why I'd suggest to use 1 thread.

Memory: Your application is probably performing a lot of other logic besides hashing, like evaluating permissions, calculating some business logic, searching data for particular complex criteria, creating reports, etc. How much memory need such requests? How much memory can hashing use so that the performance of the main functionality remains acceptable? May be after analysis you will conclude that you can use for hashing not more than 5% of the available memory. Just model and calculate.

The number of iterations: Then tune up the number of iterations to get the acceptable response time.

Then check your assumptions on the real environment with real users. If you see that performance is not sufficient, you can still tune them. After password validation against the old hash succeeded, you can rehash the password with new (optimized) parameters and save to database.


Usually full disk encryption is a two step process:

A symmetric key is generated, and used to encrypt the data.
The symmetric key is encrypted using a passphrase or similar mechanism, and stored in a predictable place on disk.
When you change your passphrase, you change the encryption of the key, but not the key itself.

The key can additionally be stored inside the TPM (bitlocker), or you can have multiple ways to decrypt the key. It can also be stored on a separate drive, or on the network.

You may notice that the key actually used to encrypt the data does not change. If that is to change, all the data has to be read, decrypted, encrypted with the new key and written to disk. It also means that if an attacker gets access to the actual key, and not merely your passphrase, changing your passphrase will not matter.


Depending on how curl is launched, it may be vulnerable to parameter injection. Since you control one parameter already (the URL), you might be able to use characters such as spaces and apostrophes or quotation marks to inject a -o <file parameter, which would cause curl to write its output to that file. If you can do that, there are lots of options (especially since curl runs as root), such as dropping a crontab file with a command to invoke your program in a minute. Less likely to work but still worth checking is whether curl is running within a shell, in which case you may be able to use shell injection (such as backticks or $( ) around a command) to execute an arbitrary command directly.

There is no way for reading a file to directly cause code execution. However, you could try reading files that might be useful for getting remote access to the box. For example, check the SSH authorized keys, and see whether the corresponding private keys are present on the machine; if so, steal them and use them to SSH in (though you might need to break a password on the private key first). You could also try stealing the password hashes from /etc/shadow and cracking them; it's a long shot but maybe there's a weak password on one account that you can guess, and then use to SSH in with password auth. Alternatively, you could try to retrieve any cloud provider credentials (AWS or similar) and use them to gain control of the host through the cloud provider's infrastructure.


Does the subject HAVE to dominate the object in order to access the object?

I think you may be confused about the terminology, if I'm understanding your question correctly.

Security levels can dominate each other.

Security level X dominates Y if and only if X is a higher classification than Y, and X is granted at least the full set of privileges Y has.  In your example X = {TOP SECRET, {A,C}} does NOT dominate Y = {SECRET, {B,C}} because while X > Y in classification, X does not contain the full set of privileges in Y.

Pauls security level doesn't have to dominate the security level of the document.  He only has to match the security level of the document and have the privileges of the document.


What is the security risk of the Macbook Pro Touchbar?

The main point seems to be the possibility of cheating. Looking a bit further at the links provided the page you've linked you get North Carolina requires test takers disable MacBook Pro Touch Bar for bar exam [u]:

  The board didn't explain its policy, but it's presumably concerned about cheating. The Touch Bar is designed to replace physical function keys with context-sensitive touch commands —a programmer could, however, conceivably write software that would display test answers.

And similar from a vendor of exam software about Disabling the Touch Bar on MacBook Pro:

  Exam Administrators will want to ensure that the newest feature included with some MacBook Pro's is disabled before a student begins their exam. By default, the Touch Bar will show predictive text depending on what the student is typing, compromising exam integrity.

Since the specific exam software is currently unable to lock down this feature during exam the feature must be either disabled manually or the system is not allowed for exam because of possible cheating.


Partial decryption using untrusted decryption service

Your premise is incorrect, but conceptually I think the problem you're alluding to has been solved by server based password managers using password based key derivation functions (e.g. PBKDF2).

Reason your premise isn't right is that symmetric encryption and decryption (e.g. AES) is fast even in JavaScript. These days the cost is low especially when many consumer devices have dedicated hardware to process it.

Asymmetric encryption (based on public and private keys) on the other hand is expensive, and if its processing becomes prohibitive in an application there's a good chance it's being mis-applied.

Although with an algorithm like AES encryption and decryption is fast, if you don't know the correct key it will take forever to guess the right one because there are way too many to guess (especially with 256 bits). This is further compounded by the use of PBKDF2, which I shall explain in a bit.

Although you say the server is untrusted, you do trust it enough to receive and store your encrypted data, but I assume you don't trust it to directly receive and store any sort of confidential data in plain text. Another assumption I will make is that the server will try to ensure the encrypted data is only sent to you, and not to everyone who simply asks for it. Assuming this is reasonable I will present a scheme using PBKDF2 that many server based password manager services utilize.

What's PBKDF2? It creates a key from another key, much like your K to K1. What's interesting about PBKDF2 is that it can be made as fast or as slow as you want - the larger the number of iteration rounds the slower it is.

Registration with server in order to establish authentication credentials and submit encrypted data:

//// JavaScript client side
PBKDF2(password, 1000 rounds) => encryption key // fast because low number of rounds
encrypt(encryption key, data) => encrypted data // fast even with AES 256
hash(encryption key) => auth key

// send encrypted data and auth key to server

//// Server side
PBKDF2(auth key, 100000) => server hash // slow because high number of rounds
// store server hash and encrypted data

When you subsequently access server:

//// JavaScript client side
PBKDF2(password, 1000 rounds) => encryption key // fast because low number of rounds
hash(encryption key) => auth key

// send auth key to server

//// Server side
// verify auth key
PBKDF2(auth key, 100000) => server hash // slow because high number of rounds

// if server hash matches what was previously stored return encrypted data
// send encrypted data back to client

//// JavaScript client side
decrypt(encryption key, encrypted data) => data // fast

Note that my reference to PBKDF2 above is a simplification to demonstrate its role rather than actual usage.

I believe this proposal solves the inherent problem that I think you're asking, without needing a new type of encryption, and instead rely on known strong cryptographic techniques. Everything on the client JavaScript side is pretty fast since you know the password/key, whereas trying to get your encrypted data then breaking the encryption from the server side are expensive.

Highlights of the proposal:

Everything on the client side is quick.

PBKDF2 has low number of rounds so is fast
AES encryption and decryption is fast

Server never privy to:

Plaintext password.
Confidential (decrypted) data.

Server stores encrypted data. To get any information from here is expensive.

Authentication required to obtain the encrypted data is relatively slow. First line of defence.
If a malicious entity somehow manages to get the encrypted data, they will still take pretty much forever to decrypt since they do not know the encryption key. Second line of defence.


How to fuzz on FreeFloat FTP server using SPIKE Fuzzing?

Sorry I cant help directly with the SPIKE component but how do you know that the FreeFloat FTP server is even insecure and will crash? It may be well written and able to handle everything that SPIKE throws at it.

In the mean time, metasploit has great FTP fuzzing modules that I have used in the past with lots of success.

http://www.metasploit.com/modules/auxiliary/fuzzers/ftp/ftp_pre_post


Is Google prompt safer then authenticator app for 2-step verification?

Google is using push notifications for that service, I'm assuming.  This puts the security roughly equivalent to an SMS-based MFA.  As you point out, they both provide an opportunity for an attacker to intercept an authentication code destined for you, or to find some way to convince Google to send the code to them directly instead of your phone.

The security analysis of a push notification-based system versus an SMS-based system then is going to be up to the specifics of the transfer protocol (i.e. is it easier to intercept SMS traffic than push notifications, or vice versa).  This is the interesting question, and one I don't know the answer to.

However, neither is going to be much safer than the other, given the inherent limitations of a network-based authentication method for "something you have".  The difference between them and an HOTP/TOTP app, or a hardware MFA device, is much more, and in turn the difference between using any of these methods and using single-factor authentication is even larger.  So from a practical perspective I think the question, while interesting, doesn't matter: any form of MFA is better than not having one at all, and if you really care about your security, you should be using a non-network-based second factor.

I'd guess the primary reason Google is rolling this out is not for increased security over SMS 2FA, but ease of use (which means people are more likely to use it instead of forgoing MFA entirely).


Tomcat IP restriction vs Two Legged OAuth

Are you talking about the authentication between users and the front-end app? or the front-end app itself and the backend?

I guess as with almost anything security related, it depends. You'd need to consider the value of the data available through this app, and compare it with the exposure it might have to compromise (external but also internal). It might or might not be sufficient using source-IP filtering, or even OAUTH, depending on this risk profile.

As for the analogy with the keys to the rooms in the house. True, you don't normally need keys to every room in the house, but when you go to the toilet, you might want to lock the door, just in case someone walks in on you. Or if you want to store the precious necklace your grand-grandmother used to wear, you might want to consider putting it in a safe. Or when you have lots of guests at a party, you might put all the expensive china in a storage room and lock it away and only leave paper cups... hope you see where this is going (and don't forget to invite us to the party!)


How did a malicious website managed to serve me the app that is running on my local apache server?

I was surprised to be presented with the web app that I am running locally on apache.

Likely the name of the domain you've typed resolved to 127.0.0.1, i.e. localhost, and thus access to the domain resulted in access to your webserver on localhost. Since you likely use relative URL's in your local site (i.e. only path but no domain given) all links now pointed to the new domain.

See also Why does localbattle.net point to localhost? and Weird DNS queries to messager.xicp.net for similar questions.


How does the SSL connection protocol work with self-signed certificate?

In the SSL protocol (now called TLS), the certificates are a black box: from the point of view of SSL, the certificates are received from the server, and somehow the public key to use becomes known to the client. The certificates are a vessel used to convey the server's public key to the client, and all the CA business is a way for the client to gain some assurance that the received public key is indeed the correct one from the intended server.

When the server uses a self-signed certificate, the client cannot transfer any trust from a known CA in order to ascertain that the received self-signed certificate is the genuine thing, and not an imitation from some active attacker. However, if the client already has knowledge of the server's public key (e.g. during some prior installation phase, under controlled conditions, the server's self-signed certificate was shown to the client, and the client remembers it), then the client, by definition, knows the right server's public key, and uses it.

In any case, the SSL-level protocol is completely unchanged. The server stills sends a Certificate message, and the client still uses the server's public key for its ClientKeyExchange message.


Can a hacked torrent client be used to prevent others from torrenting?

You can poison a particular torrent with false IPs quite easily. The tracker is just a script that takes an announcement request over HTTP(S) with a torrent's infohash, the IP address and port of the peer, and some details about how much of the torrent has downloaded for that peer. The IP given is not required to match the source IP of the announcement.

There are a number of attacks beyond this, e.g. having peers at these address which return garbage data.

In terms of defense against this, modern BitTorrent clients are quite robust. For example, DHT allows the user to reach additional clients as long as it has contacted at least one legitimate peer. Clients also detect many common tricks to falsify availability and ban those peers for the remainder of the download. This means that for a torrent with any significant number of legitimate seeds and peers, the false peers would have to vastly (1000-to-1 or more) outweigh them in order to have any real effect. Of course the side-effect here is that the torrent jumps to the top of the list on search engines, because it appears to be very popular, which is the opposite of what most intellectual property holders want.


How can clicking on a URI infect a host?

was for someone on the inside to click, or type (or otherwise GET / HTTP/1.1), and access his public URI.
Is this realistic? Surely whatever exploit and payload was used, must require more manual execution than that, right?

There is a phrasing ambiguity in this. "Is a GET enough"? -- no, of course. But is clicking a link, with a vulnerable browser, enough? It is.
It is not the act of GETting a payload that infects the system per se, the problem lies in what is used to do the GETting. That is why you want defense in depth:

proxy "guard" software to stop navigation to unsafe shores (the GET never starts),
firewall/antivirus to recognize the payload and possibly prevent it from calling home and downloading a bigger brother (the GET does not succeed),
continuous system update to ensure vulnerabilities are kept to a minimum (the GET succeeds but has no effects),
IDS to detect suspicious behaviour inside the network (the effects are detected and blocked)
backups.

If the system is not updated and a browser is vulnerable, the targeted URL might recognize the browser and send a tailored payload (which it wouldn't send to, say, a content-detection system or a site scanning service, in order to appear clean). If the vulnerability allows it, the downloaded content might be able to run itself and take control, and possibly download further, less specific malicious code.


What MySQL information should be kept secret?

Username and password are the bare minimum secrets.

Hostname and database name are convenient to have in environment variables so they can be easily changed in response to changes in the production environment.

If the mysql server is exposed to the internet, the ip/hostname might give a would be attacker of your site an interesting clue. Having mysql listen to the internet is a bad practice though, and trying to keep the ip a secret does little to help.


How does PKI help prove a site is legitimate?

It's easy to open an encrypted SSL/TLS channel with someone using asymmetric cryptography; your browser just grabs the site's public key. The hard part is knowing who you're actually talking to. Someone could be using a man-in-the-middle attack and you wouldn't know you've been given the wrong key, and thus are talking to an imposter.

That's where PKI comes in. The idea is that a mutually trusted third party, known as a Certificate Authority (CA), is has vouched for the fact that the public key you've been handed actually belongs to the owner of the domain you browsed to. For example, if you click on the lock icon next to this site's URL, you'll see that DigiCert has vouched for stackexchange.com's certificate. This means that stack exchange purchased a certificate from DigiCert and had to prove ownership of the domain as part of that purchase. The certificate is just a bunch of identifying info, including domain name, paired with a public key, and then digitally signed by the CA.

You browser comes pre-loaded with certificates from a bunch of CAs. When you browse to a web site, if the site's certificate is signed by a CA on your browser's trusted list, then everything just works. If it's not, your browser will throw an error.

In practice, the system sorta works, but there are several problems. There are way too many CAs, including companies with lousy security and governments who engage in espionage. Also, users may ignore the error their browser throws when the certificate isn't right, because most of the time, the problem is a misconfiguration, not an attack. If you want to get a better understanding of the practical problems and mitigations, check out the research of Moxie Marlinspike and Google "certificate pinning".


Why append an nop sled at the end of the shellcode?

There are two reasons for this as far as I know

The buffer overflow length might need to be a very specific number and your shell code might not take up the entire buffer. For instance if your buffer has to be exactly  400 bytes but your shellcode is only 312 then you'd insert 88 bytes worth of nops to ensure the correct length.
Shellcode can require a bit of room to "expand itself". You can typically get away with only adding a few extra nops to the end of the buffer but I've always been taught that the shellcode should have some padding at the end for successful execution.


How can I tell if a PDF file I was sent contains malware?

You can upload a pdf to VirusTotal and check if that file is infected, but be careful since results from VirusTotal are not 100% accurate.

There is also PDF Examiner.

  PDF Examiner by Malware Tracker is able to scan the uploaded PDF for
  several known exploits, allows the user to explore the structure of the
  file, as well as examine, decode and dump PDF object contents. This
  tool lends itself well to manual PDF analysis tasks. In this way, it
  differs from Jsunpack and Wepawet, which focus on automating the
  analysis as much as possible.

One more free service Jsunpack.

  Jsunpack by Blake Hartstein is designed for automatically examining
  and de-obfuscating JavaScript. Its features also include carving
  contents of network packet capture (PCAP) files and identifying common
  client-side exploits. It can also examine PDF files for malicious
  JavaScript artifacts.

For deeper analysis you should check PDF tools from Didier Stevens.

https://blog.didierstevens.com/programs/pdf-tools/


How to maintain validity of user credentials?

This organisation should have a specific landing point for customers to receive/verify/modify their PIN code, which does not depend on departments, and department staff should be trained to not give this information just as they would not give other sensitive personal information.

The reason is you can't ask departments to reason about the sensitivity of the PIN code themselves if they don't know what others are doing (or will be doing in the future) with this PIN. Also, it'd be much costlier to setup an organisational or technological mechanism for departments to check the sensitivity of the PIN in situ so they can decide whether to disclose it over the phone or not. It's easier to have a separate team for handling the PIN so a unique policy can be created, updated and enforced.

Note that at this point it makes a lot of sense to have a cross-department account management system with some amount of information reuse. You already need this for such a PIN (though I must say the primary issue probably is that the PIN exists in the first place).