should I not accept cookies for the sake of anonymity?

Cookies are used to retain information between visits to a website. This gives website the ability to remember you between visits. This allows them to provide better service, but also gives them the opportunity to analyze your long-term behavior.

Disabling cookies is a tradeoff between privacy and convenience. You have to decide for yourself if you want to allow website to recognize you immediately when you visit them or if you want to tell them yourself who you are by logging in with username and password.

Keep in mind that there are also ways to handle cookies between the two extremes "allow everywhere" and "reject completely".

Many browsers can be configured to only keep cookies until the browser is closed. This allows web applications which rely on cookies to work properly, but doesn't allow them to track you over longer timespans.
There are browser plugins which give you finer control over which websites are allowed to store cookies and which aren't. That way you can prevent advertisement networks from tracking you, but still allow your favorite discussion forum to set your login cookie.

There is little reason to visit an email service like GMail without logging in, so allowing them to set cookies is merely for your convenience because it means you don't have to enter your username and password everytime you visit them. However, keep in mind that when you share your computer with other people, you might prefer to not use cookies, because when you forget to "log out" manually, other users of the same computer will gain access to your email account just by visiting GMail. When they also use GMail they might not even notice that they are in your account.


Secure DHCP, DNS, Active Directory Server

Well of course first and foremost is patching, obviously.   Make sure that you're up to date on all security patches, and this is a critical server to keep patched.

Second, perhaps also obviously, is to limit the server to only the services and open ports required for its specific duties.  Nothing extraneous should be running on this box.

Third, and perhaps most useful, is to review and apply the Microsoft Security Baselines for Windows Server 2012 R2 for the domain controller configuration.  This is going to help ensure that you're configuring the server in a reasonably optimally secure manner.


Chosen-ciphertext attack -- basic question

The quote is simply setting up a thought experiment. The theoretical box in question just does decryption and has the key to decrypt, but the cryptanalyst cannot use weaknesses of the box to get a key.

The point of the example is simply that the cryptanalyst has access to the input and output, but not the process or key.


Reinstall your system (as you say you are unknowing, if you feel your system has a virus, reinstall your system from scratch)
Install an antivirus on your computer
Install an antivirus on your server (yes, for Linux there are solutions as well)
You know have a bit more assurance that there will be no problems

But you can't, unfortunately, be 100% sure.

Another option is that, before uploading your jpeg, you upload it to virustotal and see what that gives. If it says one of your files is infected please jump to step 1.


That's not quite what happens. As public/private key encryption is more expensive than symmetric encryption, its use is minimal. During the SSL handshake, the client and server agree upon a shared symmetric key that they use for bulk encryption. The remainder of the communication then occurs using this symmetric key. This symmetric key is then rotated on a regular basis to reduce the chances of an observer of the communication stream from guessing it.


Should content from database be sanitized again

"Sanitize", by itself, is meaningless. There is no such thing as "dirty data" as opposed to "clean data". When people think of data being "sanitized", they really mean "data which has been verified to be in a format suitable for a specific processing". For instance, if the purpose of the data is to be embedded into some SQL statement, then "sanitation" of the data involves making sure that it contains none of the characters that the SQL parser will consider as special (typically, no quotes).

A better word is validation. Whenever you must use some data, and the data is "potentially hostile" (it could have been crafted at some point, more or less directly, by an attacker in order to trigger unwanted behaviour in your code), then the data must be verified to be appropriate for the intended processing. If you "saved content into the database after sanitizing it" then chances at that you made sure that the data was in proper format for the purpose of storing it in the database. Depending on the validation steps needed to ensure safe storage, and what you intend to do with the data when you retrieve it, then this may or may not be sufficient.

For instance, suppose that the data element is obtained as some characters from the user, and should be stored in the database. The data element is supposed to be a number. However, the database-storage thing only minds about "special characters" and thus sees no problem in storing "BozoWasThere" in the database. In that sense, the string was sanitized (and the storing went very fine) but it still not a number, so this would warrant for further sanitation after retrieving it.

The concept of "sanitized data" is a great source of confusion. It is some mantra that many developers ritually utter ("sanitize all things !") because it give them the feeling that they did something about security, without having to perform that most inconvenient action known as thinking. In the long term, this does not work well.


A quantum computer, if it ever exists, ought to be able to explore a space of N possible keys in time √N. I.e. it could brought down the cost of brute-forcing a 128-bit AES key from the technologically infeasible 2128 down to the much lower but still very substantial 264 -- it will still be quite expensive, especially for a machine that does not exist yet. Note that this contrasts a lot with quantum computers trying to attack a RSA or DSA key: keys for asymmetric algorithms are mathematical objects with a lot of internal structure, and "breaking" them amounts to unraveling that structure; AES keys do not have any such structure, they just are bunches of bits.

Decoherence is the biggest hurdle with quantum computers; to build a QC, you need to put together and entangle "qubits", and make them transition between states without losing their links. To make an analogy: imagine that you are trying to put in the same room a thousand hip-hop dancers. They must all make the same moves in perfect unison. The show stops as soon as any one of them begins to make suggestive gestures purporting to characterize the morality of the ancestry or one of his fellow dancers. If you can avoid that for a full month, then congrats ! You have a working quantum computer. All you then need is to keep it going for a century or so, and you will break AES.

Optical computing does not even reach that level. A "fully optical computer" is classical in nature; for such a computer, AES brute-forcing is still a 2128 effort.

There used to be some hopes about faster computers by using optical gates, based on some preliminary analysis about bistable optical elements that could switch between states about 100 times faster than the corresponding electronic gates. This, however, does not translate to 100 times faster computers:

These measures were from more than 20 years ago. In the meantime, electronic gates were much optimized, and the gap has shrunk.
In modern computers, the gate switching time is no longer the bottleneck; what limits computing speed is the time needed to convey the information from one gate to the next. The problem is the speed of light. An optical computer does not solve that, since light goes, after all, at the speed of light. At best, a fully optical computer can help a bit in reducing the average path length between two gates because light rays can cross each other freely. Don't expect too much of a boost, though.

Moreover, even if you could make a computer that is 100 times faster than existing technology, then you would gain less than 7 bits in brute-force (because 27 = 128). A 2121 effort is far beyond what can be done with existing and foreseeable technology.

We are still using DES, if only as part of Triple DES, despite the publication of AES as a standard in 2001, and the deprecation of DES. Old technologies never die out; at one point we begin to use new ones, but not as a full replacement. Therefore, one may surmise that we will use AES forever, for (at least) backward compatibility.


Is it unsafe to restore backed up data from Google servers?

Not generally.

Like Matthew said in his comment, the restore process will not restore the vulnerable versions of previous applications unless the application is still vulnerable.

What Google does is simply store a list of applications you used. You will then have to re-download them, and most of them will probably be updated to remove previous vulnerabilities, making you much safer overall.

Imagine the horror of having to store dozens of different versions of a billion different applications. I can't see that being very efficient.

Your contacts and photos are likely safe as well.

Is there anything else to worry about?

The only thing you really have to worry about are the app permissions. Do you want to allow certain applications access to things you'd rather they didn't?

Updated Responses

In response to your update:

  What are relatively benign things I can restore from backup (that is Sync from Google servers)

Pictures, lists of previously-installed programs, contacts. Essentially, nearly everything you had before.

  and what should I avoid?

If you have any documents, avoid those. Though by now, it's possible the exploit that allowed those documents to introduce malware have been fixed in the updated applications. It's also possible it still hasn't been fixed. I would recommend avoiding them if you can.

If the documents need to be retained, you can still restore them. Don't open them, though. Save them to your computer, and dump them into a virtual machine on a different operating system such as Linux, and get the information you need from them. While it's possible to break out of a VM, it's unlikely.


Symbolic links, PATH and privilege escalation vulnerability

The attacker is attempting to get a shell running as the DavidGilmour user. Based on their explorations, the decision is to try to exploit a vulnerability in the shineon binary because that binary is setuid to DavidGilmour:

$ ls -lah /usr/local/bin/shineon
-rwsr-s---  1 DavidGilmour  RichardWright   7.3K Oct 25 07:58 /usr/local/bin/shineon

Notice the s in the permissions. That indicates that when shineon is run, it will run as DavidGilmour. But as shineon is a program of limited functionality, it doesn't have a start shell command. Instead, the attacker looks at the functionality the shell provides:

1. Calendar
2. Who
3. Check Internet
4. Check Mail
5. Exit

and then looks at the strings inside the binary. The relevant strings are:

/usr/bin/cal
/usr/bin/who
/sbin/ping -c 3 www.google.com
mail

The attacker guesses that those are the command strings used to execute the functionality of the application: Calendar corresponds to /usr/bin/cal, etc... The attacker cleverly notices that mail doesn't have a full path. This means that the script will run the first mail command it finds in the PATH. So the attacker creates a command named mail in some random directory. They chose /tmp, but that choice is unimportant. The command is a symbolic link to /bin/sh. A symbolic link creates an alias between two files. In this case, when the operating system executes /tmp/mail, it will actually execute /bin/sh. They could have copied /bin/sh to /tmp/mail as well, but why bother. Copying takes time and uses disk space. Symbolic linking is equally effective and faster.

The final step is to set the PATH environment variable to begin with /tmp so that when the OS goes to execute the mail command, it will find /tmp/mail. And, being that this is just a symbolic link to /bin/sh, it will execute /bin/sh as DavidGilmour (remember that the program is setuid so it always runs as DavidGilmour).

Goal achieved!


VPN protection against DNS poisoning on AP

This depends entirely on how the VPN is configured. Some VPNs will push their configuration (including DHCP options and the routing table) to your computer, changing your default routes to send all traffic, including DNS, over the VPN. If this is done, then your access point will not be queried for domain resolution and a malicious or compromised access point will be bypassed. To tell if this is actually done, you will need to supply more information, such as your current routing tables and the VPN client configuration file. If you are configuring your own VPN, see the above-linked how-to for instructions on pushing the server configuration (including DNS) to the client.


Why don't OS's make keystrokes available to only the current app?

Because it wouldn't help.

Most keyloggers are installed at the operating-system level, and the operating system needs to have access to the keystrokes.  Alt-Tab program switching, using Ctrl-Alt-Del to terminate malfunctioning programs, and detecting keyboard activity to keep your screensaver from activating all require the OS to see keystrokes.

There's also the minor matter that if you eliminated OS access to the keyboard, every application would need to have a complete set of keyboard drivers built into it.


In 2018, what is the recommended hash to store passwords: bcrypt, scrypt, Argon2?

I do not recommend bcrypt for new designs where the input value is human-generated token (e.g. a password) and offline cracking is in the threat model. The lack of memory-hardness is a serious problem when you consider how powerful commodity hardware is these days. While the lack of any major bcrypt-based cryptocurrencies has not attracted FPGA or ASIC mining implementations for the algorithm, there has still been some interest in attacking bcrypt using hybrid ARM/FPGA SoCs, such as in this paper from 2014. Ultimately, the lack of memory-hardness is a significant problem for modern designs.

scrypt has memory hardness as part of its design, but it has some shortfalls. For a start, there are quite a few scrypt-based cryptocurrencies and this has attracted quite a market for commodity FPGA and ASIC mining solutions that could be repurposed for cracking. Furthermore, scrypt's memory-hardness and iteration count are both tied to a single scalar cost factor. This makes it difficult to tailor scrypt to your own threat model. I recommend scrypt where it is the easiest option for password storage in the language or framework you're using, for example if it is already an inbuilt option for protecting user passwords.

Ultimately, I always recommend Argon2 as the preferred choice, for a few reasons:

It has been around for a while now - it won the PHC in 2015. There have been quite a few papers studying Argon2's security proofs, and many more studying potential ways to accelerate the algorithm on dedicated hardware. So far it has withstood scrutiny very well.
There are open source implementations and bindings for C, Erlang, Go, Haskell, JavaScript, Java, Lua, OCaml, Python, R, Ruby, Rust, C# (both Framework and Core), Perl, and Swift.
Argon2 is built around the AES cipher, and most modern x86_64 and ARMv8 processors implement an AES instruction set extension. This helps close the performance gap between the intended system and a dedicated cracking system. (EDIT, Feb 2019: It seems that newer versions of Argon2 may not be compatible with the AES implementation in hardware extensions. See comments for discussion around this)
Argon2 is particularly resistant to ranking tradeoff attacks beyond a memory fraction of one third, making it much more difficult to accelerate cheaply on FPGAs. This is because FPGA-based cracking solutions are mostly limited by memory bandwidth, and with Argon2's design the attacker must swallow a great increase in computational time in order to reduce memory bandwidth requirements, thus making the tradeoff inefficient. You can read more about this in section 5.1 of the Argon2 paper, with information on scrypt available for comparison in table 6 (under section 5) of the paper "Tradeoff Cryptanalysis of Memory-Hard Functions".
Memory-hardness and CPU-hardness parameters are separately configurable, along with a parallelism factor. This allows you to better tailor the security bound to your use-case, such as a server with moderate CPU power and a large amount of RAM.

As you noted, the parameters you choose are important. scrypt doesn't give you much choice, so I recommend picking a cost factor based on time (e.g. 1500ms of processing) in that case.

For Argon2 you have more choices than just parameters. There are in fact three different implementations of Argon2, known as Argon2d, Argon2i, and Argon2id. The first one, Argon2d, is most computationally expensive and resistant to acceleration by GPUs, FPGAs, and ASICs with limited memory bandwidth. However, since the memory accesses of Argon2d are dependent on the password, side-channel attacks that leak information about memory accesses may reveal the password. Argon2i, as its suffix suggests, selects memory addresses independently of the password. This reduces its resistance to GPU cracking, but eliminates the side-channel attack. Argon2id is a hybrid approach wherein the first pass uses the Argon2i (independent) approach, and subsequent passes use the Argon2d (dependent) approach.

Wherever possible you should use an Argon2id implementation. However, this is not always available. For a scenario in which you are protecting passwords on a server and your threat model deems memory access side-channel attacks to be very unlikely (this is most of the time in my experience) you may use Argon2d. If memory access side-channel attacks are deemed to be a potential risk, e.g. in a multi-tenant system where untrusted or less-trusted users run code on the same system that does the Argon2 hashing, then Argon2i may be the better choice.

In short: use Argon2id if you can, use Argon2d in almost every other case, consider Argon2i if you really do need memory side-channel attack resistance.

For the parameters, the only hard rules are for Argon2i, which must be treated specially due to its comparative weakness to the other options. Specifically, the number of iterations must be 10 or more, due to a practical tradeoff attack on Argon2i.

You should tweak the parameters to your own use-case and performance requirements, but I believe the following are acceptable defaults for Argon2id and Argon2d:

512MB of memory
8 iterations
Parallelism factor of 8

The speed of this depends on your processor, but I achieved approximately 2000ms on my system.

For Argon2i you must increase the number of iterations to a minimum of 10, which may require you to decrease the memory factor for performance reasons. This is another reason to try to avoid Argon2i unless you absolutely require its resistance to memory access side-channels.


public MySQL via XAMPP - security - whitelisting IP's versus VPN

IP Whitelist should kill any connection from an unknown IP.
It should be safe enough, and it's highly unlikely that an attacker will go through the IP whitelist, unless you whitelisted public IPs (school, restaurant, library, etc)
Using a VPN would be "safer", because you could encrypt your traffic and prevent an attacker on the same network as you from seeing any data other than the VPN's IP.
It also makes it so that there is two passwords/keys required - one for the VPN login and one for the MySQL server login.


What security considerations apply to a blockchain implementation for private use?

Right now for your use case, I can only think of three.

First security consideration is, is the data you plan to put in the ledger sensitive? If yes, you may need extra steps to protect what you put in the ledger. By default, the data you write is not encrypted, and is readable by everyone. There's no built in functionality of user roles and access controls in blockchain. Everyone has the ledger, everyone can read it. Nevertheless, roles and access controls can always be added at application layer.

Second, in relation to the first consideration, you need to protect all participants from unauthorised access. Since you plan to use blockchain for internal company use, I would assume that outsiders are not supposed to have access to your ledger. Using blockchain can potentially increase your attack surface, wherein every participant is equally desirable as a target since they all have the ledger and potential to participate in the blockchain.

Third, blockchain is supposedly incorruptible through consensus, meaning it should be nearly impossible to forge or tamper an entry by any means. If your nodes are quite small, you may not get this benefit, and could make it possible to tamper or forge through collusion. This can easily be remedied by ensuring there is a large number of participants, but could in turn potentially reinforce the second consideration.

These are quite generic, since the case you provided is quite generic as well. Security controls would depend on which of these are applicable to you. Hope this helps.


What are some common security problems for companies offering internet to guests?

If the network is in a different VLAN and router/switch has a secure password, you have no worries.

Don't mind if bittorrent port is open. First, firewall must worry about others things, if you close all ports, this is a limiting freedom to use this net, perhaps someone is using this port for a VPN connection. I think the worst problem  is that if you do not use a key to cipher channel, all messages could send in plaintext.


Should diffie-hellman parameters be unique to a vhost

There is no formal problem, from a cryptographic point of view, in reuse of the same DH parameters (modulus and generators) by multiple people. What the recent Logjam attack highlights is that if the modulus is so small that it can be broken in practice, then the attacker can reuse most of the attack effort for subsequent breakages of DH instances that use the same parameters. In that sense, it can be argued that sharing the same DH parameters with the rest of the Internet increases the consequences of a successful cryptanalytic break; however, it can be equally argued (and, in my opinion, more convincingly) that the real problem is using the same weak modulus as everybody else lies in the "weak", not in the "same". If you use a properly generated 2048-bit modulus then no breakage shall occur at all, and sharing is harmless.

You may notice that elliptic curve variants of Diffie-Hellman commonly use the extremely widespread P-256 curve, so that's Internet-wide sharing, and that does not appear to be a problem. Arjen Lenstra once told me that it made that curve a "big, fat target", and I agree with him, but, right now, there is no known way to break that curve in realistic time. (Everybody uses the same curve because producing your own curve is not very easy, and also because specializing implementations for a single curve grants some extra performance.)


What's the advantage of using PBKDF2 vs SHA256 to generate an AES encryption key from a passphrase?

The difference is that:

PBKDF2 by design is slow
SHA256 is a good hash function; it is not slow, by design

So if someone were to try a lot of different possible passphrases, say the whole dictionary, then each word with a digit appended, then each word with a different capitalisation, then two dictionary words, etc. then this process would be much slower with PBKDF2.

But if your passphrase is truly secure, that is very long, pretty random and out of reach of any systematic enumeration process, then it makes no practical difference, except that an attacker may spend more resources trying to break your passphrase (or maybe less if they decide to give up sooner).


Five years is a long time in Information Security. Ten years will see the security world decide that some algorithms and keys are too easily compromised. I have a client who had implemented SHA1 hashes in each tier in order to support unpatched Windows XP using a PKI environment that was built within the last four years. We had to rehash each CA's certificate with SHA2 well before a new key or certificate would have been required. Plans change.

You should have plenty of time to research and decide on whether simply renewing or rekeying a certificate is appropriate at each stage. I don't think it's a bad plan to rekey since better, more accepted algorithms (or longer keys) will most likely exist when that span of years has past. The big hurdle with this approach is testing every application that relies on your PKI before rekeying or changing algorithms.

If you work in a Microsoft Windows environment, this is a great resource (although out of print and often expensive):
http://www.goodreads.com/book/show/2075482.Windows_Server_2008_PKI_and_Certificate_Security


Within a man in the middle attack the attacker is in the path between client and server and can thus sniff and manipulate the traffic. This is for example possible if the attacker is a government agency which has sufficient control over the traffic leaving and entering the country, as it was true with Iran in this specific case.

In the context of SSL this is used by terminating the connection from the client at the attackers system and then creating a new SSL connection between the attacker system and the server. I.e. the attacker decrypts the traffic from the client, analyzes and manipulates the unencrypted traffic and then encrypts it again when sending it to the server. And the same for traffic from server to client.

In order to terminate the SSL traffic the attacker needs to have a certificate which will be accepted by the victim (the client). Usually the attacker does not have such a certificate which was issued by a publicly trusted CA which causes the client to display a warning that the certificate is not trusted. But in this specific case the attacker could compromise a public CA and make it issue the necessary publicly trusted certificate. With no certificate or CA pinning the browser will simply trust this new certificate since it was issued by a CA trusted in the browser.


Extremely high bandwidth usage for OCSP?

Does this seem legit?

It is impossible to know just from bandwidth numbers. It's like asking "is this charge on my credit card legit?" - it depends on if you made the purchase.

  Any ideas as to what could be causing it?

You have a basic network troubleshooting scenario here. Set up packet captures within the network or logging on the router and see what is making the requests, then you can narrow down which devices are making the requests.


How can I determine from where injected script came from?

To begin with you can try and check the timestamp of those files. You might be looking at more than one infection; if your site is vulnerable and has been scanned by X different bots all looking for the same vulnerability, you might have as many different scripts hacked by different sources.

Then check what requests came at around that time or very few seconds before, and see whether you detect any pattern.

As a good practice, the user running the Web server (be it apache, daemon, nobody, or www) should not have write permissions on any web directory except temporary upload and sessions; and files deposited there should not be reachable (e.g. with a read-only .htaccess file in the same directory denying access to that directory and all its subdirectories).


When do honest people need privacy or anonymity? (e.g. they have nothing to hide)

There's a great short essay written by Bruce Schneier on the right of privacy:

  The most common retort against privacy advocates -- by those in favor
  of ID checks, cameras, databases, data mining and other wholesale
  surveillance measures -- is this line: "If you aren't doing anything
  wrong, what do you have to hide?"

  Some clever answers: "If I'm not doing anything wrong, then you have
  no cause to watch me." "Because the government gets to define what's
  wrong, and they keep changing the definition." "Because you might do
  something wrong with my information." My problem with quips like these
  -- as right as they are -- is that they accept the premise that privacy is about hiding a wrong. It's not. Privacy is an inherent
  human right, and a requirement for maintaining the human condition
  with dignity and respect.

You can read it in full here: https://www.schneier.com/essays/archives/2006/05/the_eternal_value_of.html


How do I know that I'm vulnerable to the: " Coordinated Website Compromise Campaigns Continue to Plague Internet "

As far as I can tell, there isn't enough public information to know which systems are vulnerable. The Cisco blog you linked to appears to be the primary source for this news (other sites have since picked it up, but add nothing), and it does have any concrete information on the infection vector.

The Cisco blog now includes the following edit (emphasis mine):

  The observation of affected hosts running Linux kernel 2.6 is
  anecdotal and in no way reflects a universal condition among all of
  the compromised websites. Accordingly, we have adjusted the title for
  clarity. We have not identified the initial exploit vector for the
  stage zero URIs. It was not our intention to conflate our anecdotal
  observations with the technical facts provided in the listed URIs or
  other demonstrable data, and the below strike through annotations
  reflect that. We also want to thank the community for the timely
  feedback.


This was answered at SANS' forensic blog in the comments section, here is the excerpt:

QUESTION

  Are not you running all the commands in this article on your trusted
  workstation?

ANSWER

  Yes, I'm running them on my trusted machine. However, if I run 'psexec -u' from my trusted machine, it sends the password to the
  remote untrusted machine and performs an interactive logon. We need to
  avoid this. So one workaround was to use RunAs to lunch a new command
  shell as my privileged account on my trusted machine and then logon
  using psexec without '-u'. This avoids sending the password and
  creating the interactive logon on the remote untrusted host.

QUESTION

  Are not your hashes going to untrusted machine with runAs?

ANSWER

  Not in the scenario I just described, because I would be authenticating with a network logon.

QUESTION

  are your hashes will stored on your trusted workstation or where?

ANSWER

  Yes, the hashes of my privileged account will be stored on my local trusted workstation once I use RunAs to start a command shell as
  that user.

QUESTION

  How a workaroud is that I coudlnt get it.

ANSWER

  If you're asking why it is a workaround, it's a workaround in the sense that I can connect to a remote machine using a privileged
  account without having to use the '-u' option. Instead it uses the
  credentials of the currently logged on privileged user within the
  RunAs session.


How to generate Initalization Vectors correctly

TL;DR, the particular requirements of IVs depend upon the mode of encryption you're using. The one common attribute is that all IVs must be unique.

In modes like CTR and GCM, uniqueness is the only requirement. The IV in this case is also commonly referred to as a nonce (i.e., a "number used once"). Even a simple counter would suffice, as long as it is guaranteed not to ever generate a duplicate (even across multiple machines, or in the event of software failure).

In modes like CBC, the IV must be indistinguishable from random by an adversary.

For IVs with a large enough size (e.g., at least 128 bits), a cryptographically secure random number generator (CSPRNG) is usually considered sufficient. For algorithms involving IVs that are small enough such that random collisions are probable (for instance, Salsa20 has a 64-bit nonce), a CSPRNG is not appropriate since it would generate collisions. Another scenario where a CSPRNG might not be usable is in embedded devices, which may not have the ability to generate sufficiently random numbers in hardwaree.


GPG unattended ECC key and subkey generation

In the section above "Unattended generation" you list "Config contents" to batch generate a master key and then provide details for TWO sub-keys.

When the facility for batch file processing was added to GnuPG, the batch generation of a master key with only ONE sub-key was provided.

https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html

          "Currently only one subkey can be handled."

This is why you are getting the error message "duplicate keyword".

In order to add multiple subkeys to a key via a script, there is no builtin script support and you should take a look at the solutions provided at

https://serverfault.com/questions/818289/add-second-sub-key-to-unattended-gpg-key

There is also a further difficulty concerning ed25519.  Creating an ed25519 key or sub-key for "encryption" is only possible with GnuPG v2.1.7 and an ed25519 supporting version of libgcrypt.

https://www.gniibe.org/memo/software/gpg/keygen-25519.html

So unless you are using GnuPG v2.1.7 (with suitable libcrypt) trying to create an ed25519 key or subkey for encryption is going to fail with an error message.


sniffing with wireshark on wireless network

Wireshark attaches to an interface, it may be your wireless interface or even loopback. Then it intercepts every packet in that network.

If your interface is in promiscuous mode then it will capture everything in the network that this interface is connected to, but not everything in the air, just what goes on in that network and in that interface.

Edit suggested by AstroDan:
The official WireShark documentation includes a section about Promiscuous mode that is worth reading


The Creation of Secure Software Development Environments

This is one of the elements in the OpenSAMM Open Software Assurance Maturity Model as from a governance perspective it is essential to have appropriate separation of development, test and production environments.

Without this separation, there are a number of key risks, including:

a change to code that has not been tested could very easily delete or corrupt data in a production environment, or even break the system sufficiently to deny service
a developer with access to a production or test environment could subvert system controls in order to commit fraud, disrupt systems or gain unauthorised access

Companies in regulated industries tend to have this separation enforced under audit rules (eg Financial Services) but most industries recommend this as good practice.

In the US, CMMI-DEV, listed on this page is also appropriate, and most SDLC programmes do mandate or at least recommend secure software development environments.

There are also elements in ISO27001:2005 which do apply, but I think they aren't formalised enough yet.


I experienced the same issue in the past. I think you experience the same problem (it is described here)
Please answer the following :

What software did you use to capture the handshake ?
If you open the handshake with Wireshark, how does it look like (screenshot) ?
$ pyrit -r "yourcapture*.pcap" analyze give you what status (good/workable/bad)?
Did you 'clean' the capture using 'wpaclean' or other tool ? (In my experience it can damage your pcap rather than 'cleaning it properly')

The only solution I have found at the time was to capture a new handshake / or clean it myself.


MD5 security concerns in download verification

I prefer CIC's comment-answer, but the way I have always viewed it is that collisions aren't always useful.

Maybe two text strings can have a collision and if they fit in a password input field, that's a problem.

But what are the odds of useful malicious code, that actually works, being injected into another program and generating the same checksum? Probably absurdly small.

You'd need a wonder-computer to take the legit software + malicious code, and figure out what kind of garbage data needs to be added to the file in order to create the same checksum and filesize and all of that.

This of course assumes the hash is preimage resistant. The wonder-computer being something that not only make the infeasible feasible, but also finding a collision that has both functional legit software + malicious code.

So in that regard, not really a security concern.


Are there any vulnerabilities when making cross-domain HTTP requests during an SSL connection?

This question is entirely dependent on what content is being loaded and what browser you are using.  (Which is information that is curiously missing form this post)

Chrome by default will avoid mixed-content vulnerabilities by loading resources over HTTPS if possible.  Firefox will be introducing this security feature shortly.  IE lacks many modern security features,  and is especially vulnerable to Mixed Content vulnerabilities.

If you are loading JavaScript from an HTTP source on an HTTPS page,  then the entire page is compromised.  An attacker could introduce arbitrary JavaScript and read any content within that session (similar to XSS).   Flash objects that have allowscriptaccess enabled will also have access to any content within this HTTPS session.  CSS is normally not a concern, however, Internet Explorer allows you to embed JavaScript within CSS,  which would allow an attacker to read arbitrary content within the session.

So what about images and video?  Well you could Goatse someone (kids still do this right?) or flip images upside down,  but that is less of a concern than reading credit card numbers or obtaining a user's password or reading a cookie with the Secure flag set.

In the URLS above OCSP requests are usually in plaintext.  Hijacking a crossdomain.xml isn't much of a concern,  especially when the file in question already has the least secure rule-set possible:

<allow-access-from secure="false" domain="*"/>


According to The Hacker News, here are major improvements :

WPA3 protocol strengthens user privacy in open networks through individualised data encryption.
WPA3 protocol will also protect against brute-force dictionary    attacks, preventing hackers from making multiple login attempts by
using commonly used passwords.
WPA3 protocol also offers simplified security for devices that often    have no display for configuring security settings, i.e. IoT
devices.
Finally, there will be a 192-bit security suite for protecting WiFi    users’ networks with higher security requirements, such as
government, defence and industrial organisations.

Thus I think it has some security improvements over WPA2


Yes, a CPU-based DoS on SSL servers is easy. Consider the two main types of cipher suites, as commonly used in SSL:

RSA key exchange: server sends its certificate with a RSA public key; client generates a random blob (the pre-master secret key) encrypted with the server's public key; the server decrypts it.
DHE key exchange: server sends its half of a Diffie-Hellman key exchange, signed with the server's private key. Client sends its own half of DH. Server completes DH key exchange by applying its DH private key (a modular exponentiation).

Either way, the server must perform a relatively heavy cryptographic operation: an RSA decryption, or a DH modular exponentiation (for DHE, the server can reuse its ephemeral DH parameters, as long as it does not reboot, but it cannot evade the final modular exponentiation computed over what the client sends). On the other hand, a client who tries to DoS the server does not need to do any work at all: it just needs to send a blob of approximately the right size. Decryption on the server will fail, but the CPU expense will be lost nonetheless.

(Already with honest clients and RSA key exchange, the CPU cost is higher in the server, because RSA encryption is much faster than RSA decryption. But an evil client, intent on DoSing, can totally avoid work.)

Such attacks have been observed in the wild and it does not take an academic paper to explain how they work.


What is a good practical (and sane) way to manage all your passwords for online sites?

What I do is the following:

I write the passwords down.

Many people will cringe and scream and curse me and say that this is wrong and should never be done, but this is too simplistic an assertion. Details matter. Here are the details:

I keep the passwords in a text file.
When I get out of my home and must access my passwords, I bring with me a netbook. That computer has a few specific characteristics:

It runs Ubuntu (a Linux distribution).
No swap space is configured. What is "in RAM" is really "in physical RAM" and never makes it to permanent storage.
The /tmp directory is a tmpfs, i.e. the files in that directory are only in RAM (and that's physical RAM, see above).
I always shut the machine down; I never put it in "sleep mode".

Under these conditions, I have a reasonable guarantee that if I write a file in /tmp, read it, then shut down the computer, then the file contents will not be accessible to any evildoer who would steal the machine.
My file full of passwords is symmetrically encrypted with GnuPG, with a big, fat, strong passphrase (that passphrase, I keep in my brain).
When I must use a password, I decrypt the file in the /tmp directory and I erase it immediately after; and when I no longer need to use the computer, I shut it down, as is my custom.

Under these conditions, my passwords are reasonably safe. This is not perfect: if my computer is hacked in silently and the attacker can observe everything I do for a long time, he will get my passwords -- but he would get them anyway under these conditions, if only by plugging some evil code in the Web browser itself (regardless of how you manage your passwords, the Web browser code gets them at some point, since it must send them to the servers who ask for them). I claim that my method is much safer than the common alternative, which is reusing passwords on several sites. Do not reuse passwords !

(In practice, I very rarely have to access my file of passwords, because I remember the passwords I often type -- and those I do not often type, well, I type them rarely, by definition.)


Are .NET WebServices vulnerable to CSRF?

Without providing more detail about your web services,  I would say yes there is a very good chance it is.   However the exploit is probably not what would expect as it is different from your usual HTTP POST/GET CSRF exploit.  In the case of SOAP or other web services the body of the message is XML or some other block of data.  When I write PoC CSRF exploits for services like this I am forced to use ActionScript's request.data feature.  It also should be noted that many, but not all of the http request headers can be set and modified with ActionScript.


Should we use x509 V1 certificate for a new root CA?

My question is, is it still a norm today to use v1 certs for root or self-signed certificates?

No, no and no. For certificates issued within last 20 years only Version 3 X.509 certificates shall be used.

  Is there any other place where usage of version 1 still recommended?

no, there is no such unless you need to support software or hardware that doesn't support V3 certificates (I doubt you can find one that is still in active use and cannot be replaced).

V1 certificates are still supported by cryptography libraries, but they are hard to use, because certificate behavior may vary on different platforms. For example, it is impossible to determine the subject type of the certificate -- is it CA or end-entity? Is it allowed to sign other certificates? There is no such information in V1 certificates. And different platforms may treat them very differently. With V3 it is clear: if Basic Constraints extension is presented and isCA bit is set to True -- it is CA certificate, otherwise it is end entity.

In addition, V1 make chaining engine less reliable, because only name match can be used when binding certificates in the chain, thus much more chains can be constructed and more chances that inproper chain is selected. V3 allows both, KeyMatch and ExactMatch which produce less chains (ExactMatch produces only one chain in all cases) and is less error-prone.

In other words, V1 certificates are museum history. You may know key properties and features provided by V1 certificates, but use only V3.


How to perform security exploits/penetration on devices like iPhone's, PSP's, and Android to run your owncode?

Finding exploits which allow you to run your own code on platforms like these is very difficult. You would need to be fluent in the native language of the platform, almost certainly in addition to being fluent in assembly for whatever architecture it was running on. Failing that, you'd need a very good understanding of the hardware by reverse engineering what you had, as well as the right kit yourself to perhaps modify the code on FPGA's or flash chips to load your own stuff.

The software route typically involves getting a dump of the systems firmware and looking for buffer overflow exploits. These allow you to load your own code into memory and have an otherwise inert program execute it for you.

The hardware route usually involves extracting chips and reprogramming them or taking advantage of some kind of design 'flaw' which allows you to trick the existing software on the platform to doing something you want that it wouldn't otherwise do. A good example of this is geohot's original PS3 exploit, where he used a switch to stop the kernel's memory deallocation messages getting through, allowing him access to kernel pages he could read and write to and execute with ring 0 priveleges!


Indexing encrypted data for efficient searching

Ability to narrow searches tends to be in direct opposition with the confidentiality that you seek through encryption. For instance, if you store your "16-bit hash" in an extra column then that hash reveals 16 bits of the data -- 16 indirect bits, but 16 bits nonetheless. An attacker who sees the database may try to guess (brute force) the record contents, and the 16 bits will allow him to detect 65535/65536th of bad guesses: this is a substantial advantage.

Ability to do substring searches is even worse, since it necessarily reveals information that allows the brute force attack to proceed in gradual steps (this is in fact the same problem as partial password authentication).

At best, what you could do is to implement deterministic encryption, such that encryption of a given record value always yields the same encrypted result. This leaks a modicus of information (if two records have the same contents then this will show, despite the encryption layer); on the other hand, it allows for exact searches: you encrypt the value to search, and use the index on the encrypted values. Substring searches, however, should be avoided at all costs.

I think a better method would be to revisit your assumptions:

  However this will probably change in the future so I am anticipating efficency problems.

Usually, performance issues don't exist until having been actually encountered (at least in a test platform, if not in production) and duly measured. As Donald Knuth once wrote: premature optimization is the root of all evil.

Even if the envisioned performance issue is real and you know how much it will cost, some alternate methods might be applicable. For instance, you could read all the records in the RAM of the application, decrypt them all, and keep them in RAM. This would allow very fast searches without even going to the SQL level. Modern servers have a lot of RAM. As an example, the servers that maintain the StackExchange sites (all of them) are reputed to have been sufficiently boosted in RAM (a few hundred gigabytes) so that all the data can be cached, and the servers can perform all read accesses at RAM speed.

If your records are, say, no longer than 100 bytes (e.g. they are the names of some people), then you can store 10 millions of value in a mere gigabyte of RAM. What is a gigabyte ? Even your phone has more RAM than that.


Do I need CSRF token, and how it adds me additional protection (Angular/Node SPA)

The token needs to be validated outside of the cookie mechanism also.

Say evil.example.com open in Alice's browser makes a cross-site request to yoursite.example.org, then the browser will send all her cookies to yoursite.example.org, including session cookies or any other cookies you may be using to prevent CSRF.

To mitigate this, you need to send the token using another method also (I'm describing the Double Submit Cookies because it is quite simple). For example, you could include a hidden field on your form:

<input type=hidden name=csrftoken value=12321231 />

On the server-side you simply check that your session value (or cookie value) that you are using for CSRF matches the one in the hidden form field. An attacker can not then forge a request because they do not know this value, nor can they retrieve it for the current user. This value needs to be generated randomly per session (using some source of unpredictable entropy).


Connection to Google websites is not secure

Since it does not complain about a bad certificate it is probably not related to MITM attacks. And since the original google.com is usually not mixed content I doubt that this message is caused by google itself.

Therefore I suggest that it is an in-browser issue, like some browser extension injecting code into the page where the code tries to load external resources using http instead of https. Thus check out the extensions you use and see if the issues is resolved when switching off specific extensions.

If you are in a corporate environment or have a local anti-virus working as a proxy there might still MITM in the form of SSL interception which then changes the page. To find out look at the certificate chain.

Apart from AV there is other software which injects its own root CA into the system. A typical example is the infamous Superfish which came pre-installed with Lenovo-Systems and which "enhanced" the browsing experience by injecting advertisements.


Safely use compromised USB drive to transfer data from one PC to another

It depending on the Operating System you are using.
If it is a Windows machine, first I would recommend you formatting that usb disk drive into ext4 format, CAUTION: if you format the USB drive, as I am suggesting above, the information on your USB drive will be deleted forever!, but will prevent any automated scripts from executing when you plug in the USB. Then you can use command-line utility like robocopy:
robocopy C:\SourceDir E:\DestDir /E

the flag /E will also copy the empty folders as well.
If you are on a Linux machine, I would recommend using rsync, but first make sure your USB drive is mounted to your system. To find out your USB device use command tool like lsblk.
If you are moving from Windows machine to another windows machine, you could also download rsync utility for windows and use it. it will be preserved and you can always resume the copy if something interrupts the copy process


Exploitability of use-after-free vulnerabilities

Use-after-free attacks require the attacker to be able to allocate some memory reliably on heap.

Say I have an object that takes 16 bytes, and happens to be allocated in memory to 0xb00000004 (completely made up numbers here). I delete this object and the memory is returned to the heap. Now I request another heap allocation for 16 bytes (a string for example) and the heap allocates it on 0xb0000004. Now a pointer referencing the old object instead calls the new object, not even realizing it.

As you've previously mentioned, this is popular with scripting languages for a reason. That reason is because scripting languages can reliably allocate memory on the heap.

Therefore to know if you're going to be vulnerable, you need to assess how difficult it would be for an attacker to be able to allocate memory, and if that attacker could allocate it reliably.

In a C program, the potential risk appears to be less since any such pointers or references are going to be on basic data types, not objects. How is an attacker going to execute arbitrary code when the program treats it as data instead? In that case you need to analyze if your data can be trusted.

For example, let's say your program stores a string "http://xyz.com/super program.zip", and you have code to download, extract, and execute it. If an attacker is somehow able to overwrite that string to http://superbadplace.com/supervirus.zip/", then your program could unintentionally be installing a shell.


If you really did check the WAN side of your router and found these open, you have a real problem.

If that is really the case, I recommend disconnecting it and doing a factory reset and upgrade of the firmware.

In particular, the TELNET port should NEVER be open since that is allowing unencrypted login and access to a machine, maybe even your router.

I rather suspect though that you checked the LAN side not the WAN side.


Are COMET installations immune to "Slow TCP Reading" DoS on Windows? (Such as SignalR or WebSync)

WebSync runs directly on top of the IIS/.NET stack, and so it relies on the Windows/IIS kernel to process TCP/HTTP for both long-polling and WebSocket transports. I believe SignalR does this as well.


Yes, if you run a full Man-in-the-Middle attack and succeed at breaking through the SSL layer through some method (not POODLE, it does not do that, but FREAK and Logjam, when applicable, are a possibility), then, by definition, you control everything that the client sends and receives. So you could send redirect HTTP requests to make it connect to some other server.

However, still by definition, you can do the MitM because you arranged for all the incoming and outgoing traffic of that client to go through your systems. Therefore, any attempt at turning the client into a DoS agent will make it send these requests to you. So you are really DoS-ing yourself. Thus, this is pointless.

A better model would be to use this hijacked connection to try to induce the victim into downloading some malware that will give full control of his machine to you, and allow you to come back later (when you no longer intercept all I/O traffic) to pursue some nefarious deeds such as sending spam or, indeed, run DDoS attacks (assuming that you succeeded at infecting a lot of people's machines).


There are essentially only two real versions of the SSH protocol, SSH-1 and SSH-2.

SSH-1
SSHv1 had several iterations.  Each iteration fixed certain security issues, but the protocol itself is vulnerable to several attacks.  It uses RSA to encrypt 32 bytes of session key.  It uses both the server's key and the host key; as in it RSA encrypts the session key twice.  I know this sounds weird, but this is what happens.  Then the session key is shared with the server.

This protocol has inherent known vulnerabilities.  SSHv1.5 is known to be vulnerable to injecting data into encrypted packets [1].  This is due to poor integrity checking using CRC32.  SSHv1 is also prone to Man in the Middle (MitM) attacks.  Here is a paper on the subject.

SSH-2
SSHv2 is a completely different protocol.  It uses an Ephemeral Diffie-Hellman exchange with proper integrity checks of the entire exchange.  The entire packet is encrypted, including any SSH header information.  Session keys are generated from hashing the session id, shared secret, and the hash of the exchange with an ASCII letter.  There is a different letter for each session key needed session key or initialization vector needed.

The vulnerabilities in SSHv2 have only been theoretical.  So far the protocol is known to be secure when implemented correctly.

SSH-1.99
This isn't actually a version of the protocol.  The first piece of data exchanged by the client and server is their protocol version in what's called a protocol string.  This is the only compatibility the two protocols share.  Examples of version strings

SSH-1.99-OpenSSH_2.5.2p2
SSH-2-OpenSSH_2.9p1

SSH-1.99 is only ever sent by a server and it's how the server tells the client that it supports both SSH-1 and SSH-2.

You should always use SSH-2.  SSH-1 is known to be insecure.  99% of servers out there support SSH-2, and no known vulnerabilities against it.


Linux: Whitelist device file access to programs

The way to do it is to check the permissions of the device "file" under the /dev folder. Then normally, you would add the user that is running the program to the group.

You can obviously change the permissions on the device file but doing so may well break other things in the OS which may be expecting a certain set of permissions and access.

All access in Unix/Linux is generally done by controlling what users/groups can access which files/folders and what they can do with them (read, write, execute).

So the direct answer to your question is yes. Create a specific user or group to run your app and only give that user/group access to the device file. Just be aware that you might get unexpected side-effects. You should not try to force apps/devices to require elevated rights via SUDO if you don't need to.


why would keyloggers be used for stealing money less often than banking malware?

The main reason could be the attack vectors used to spread them.

You can read from the documentation you linked to that malware banking (trojans mainly) are quite easily spread via spams and  or by intercepting the user's payment data  after injecting random HTML code in the web page displayed by the browser (if you read The Emperor’s New Security Indicators: An evaluation of website authentication and the effect of role playing on usability studies, you will notice even most bank users who are taught additional instructions to behave securely are trapped easily by attackers).

Whereas it can be more complicated to fulfill the same goal with the use of keyloggers. If you look how some bank keyloggers have been a successful attack you will notice it is quite difficult for the attack to take place. It is the case, for example, for the famous Sumitomo bank keylogger that was successful only after a cleaning staff placed hardware bugs onto the keyboard sockets at the back of the bank's computers where they could not be seen and then reattached the keyboards and this  gang are understood to have also got around the bank's 24 hour video surveillance of its offices as tapes that would have shown the cleaners at work have now been found to be blank. As you can see, this keylogger needed more resources (human, mainly) to be successful.


Comparison between Firefox password manager and chrome password manager

Firefox's Sync is a locally AES-256-CBC encrypted database of your stuff (which can include passwords), stored on Mozilla's servers.  The key does not leave your browser in an unencrypted form that can be decrypted by anyone but you.  But it does end up on every Firefox browser you sync with.

The Sync key is stored locally in your passwords.  If you don't have a Firefox Master Password, it's not encrypted on your machine.  If you use a Master Password, the Sync key is unencrypted from the moment you enter it into Firefox.

The Sync key is available from your browser.  Go to Options/Firefox Sync, click the "Manage Account" tool, pick "My recovery key", and it will produce a printable version of your key.  You can type the user's email address and that key into any other instance of Firefox and you will be included in Syncing, and have therefore have full visibility into all Synced passwords.

Just like a logged-in Lastpass client, and just like Chrome, the security of the data relies on the user to deny access to parties that might compromise their password.  Anyone's email account is practically a given, so all secrecy lies in that key.  Do you Sync to your cell phone?  Might want to think twice if you're prone to losing phones.  Do you lock your desktop every time you step away from it?  Perhaps it's time to get into that habit.

There is no extra magic Firefox can apply.  Convenient tools that save passwords expose you to extra risk, regardless of who makes them or who gives them away.  It's up to you to determine if the convenience is worth that extra risk.


REST API authentication with JWT and CSRF protection for SPA

Is this implementation safe enough? What are possible drawbacks and
  vulnerabilities?

JWTs are self-describing Bearer tokens. The two major drawbacks of JWT are stale tokens and the inability to expire them on-demand.

Stale tokens

If the role of your user changes, it will not be reflected in the issued token. You will need to issue a brand new one. Ideally, you would expire the one before, which brings us to the next problem.

No on-demand expiry

JWTs cannot be expired on demand as they are themselves stateless. An approach to solve this is JWT blacklisting, but that will kill your server's statelessness. This also means that your user cannot essentially log out of your application since you cannot invalidate tokens on-demand.

About the short lived tokens. If the attacker is in possession of a short lived token, he can just query your API to "keep it alive" for as long as you let him (8 hours or 1 day).

You will need to decide if this is safe enough. It all depends on what trade-offs you are willing to make.

  Anything wrong with this approach other than opening the
  implementation to a CSRF attack?

This works perfectly. I have seen a lot of websites use it. You do need to worry about CSRF though. Unless your API is JSON only. See here.

  If I include a token inside a JWT, is it considered cryptographically
  tied to a security session?

Yes, although you cannot rotate this secret effectively because of the on-demand termination problems I described above. This is, again, a trade-off.

  Conceptually, do you see anything wrong with this implementation?

I, think what you described is perfectly reasonable. It does have its drawbacks and trade-offs, but only you know the exact business case you need to support. If no logout, stale tokens, and a fixed CSRF token per session are acceptable, then it's all good.


Server to Server Communication RSA or x509 Certificate

If you just want to make sure that the client owns a specific private key than it is enough to have a key based authentication. This is done by SSH for example.

But this requires that each server knows the public keys for each client which might want to authenticate there. This might work for a few clients but does not scale well for lots of clients or multiple servers. In this case a PKI (public key infrastructure) is preferable with some central certificate authority (CA) issuing all the certificates and the servers can simply accept all certificates issued by this CA (but need to check also expiration and revocation) and get the information about the client from the subject.  While this is more effort in the initial setup it scales better if many peers are involved.


Can someone read a iOS class variable from outside the app?

Yes, it is possible to read iOS class variables from outside of an app. Depending on your perspective and proclivity towards jailed or jailbroken devices, you may find a few ways to read them at runtime or in-memory.

Via runtime, on a jailbroken device, a tool such as NCC Group Introspy is a developer-friendly tool that doesn't require any formal reverse engineering exposure or experience.

For accessing memory in the iOS Simulator or on an iOS device, lldb and gdb can be utilized to dump an app's current memory state. One would need to identify the process to be dumped and perhaps overcome any self-modifying or self-checking code that would include process dumping. This typically requires either a Unix or a reverse engineering background. As a lighter approach, Xcode does provide a debugger, notification spy, and a DTrace interface. One common way of accessing memory without a debugger is to get an app to crash and then go through the artifacts found via the Xcode Organizer. Another way in the iOS Simulator is to go into the menu option Hardware and select the Simulate Memory Warning option.

For those who do have reverse engineering experience and a jailbroken device, be sure to check out Snoop-IT as a first-rate tool to go deeper than what Introspy above provides. Snoop-IT is also heavily covered in the books The Mobile Application Hacker's Handbook as well as Learning iOS Penetration Testing. However, my top recommendation for those who have gdb experience is to follow the techniques outlined by NetSPI to get access to the full app heap. Other techniques include using lldb on a jailbroken device by using a debugserver, which is even more-detailed on the mSecLab blog, but also covered on versprite, isa56k, and a bit on lldbpy via lifeform-labs. The last technique I might mention for jailbroken devices (or for any OS X install) is the kdv tool which utilizes the KDebug mechanism, although certainly other kernel memory dumping options are available such as readkmem. MEMSCAN and Radare (see the NetSPI blog post about adding the Radare repo to Cydia) can also be used to search through or dump process memory on an iOS jailbroken device.

There are a few techniques that can be accomplished while in the iOS Simulator. The recent book iOS Application Security covers many of these in-depth. I might also recommend that you check out some anti-anti-reversing techniques such as the ones typically done on OS X, as they will also apply to iOS. For example, a game trainer for OS X called Bit Slicer and its underlying techniques can be mapped. Basic problems with debugging (e.g., if the NetSPI gdb technique above does not work) can be worked out with idapython as seen when this author ran into a problem with anti-debugging during a MyWi reversing effort. As this article on anti-anti-debugging suggests, a catalog of techniques formalized as a GitHub project called pangu can be bypassed by another GitHub project named Onyx-the-Black-Cat. There are many other reversing challenges, so I suggest you check out the ReverseEngineering.StackExchange tagset for iOS or similar resource.

For jailed devices, I suggest you look into repackaging apps with cycript and/or Frida. If you can get a remote cycript shell, then you can use the mSecLab methods for analyzing memory of an app as one would do on a jailbroken device.


Is uncompromisable obfuscated x86-64 execution possible?

No, nothing that is secure anyway.

Currently available systems are standard methods of making sure an app can't be run without a license. However these can be reverse engineered relatively easily.

Secure obfuscation is a topic of current research. So far it has not been implemented yet but mathematicians are working on it. One method is using cryptographic multilinear maps.


Better security - Session ID in cookies vs. Encrypted cookie

The security difference will mostly be in the implementation details. Fundamentally both approaches are the same: you store a blob of data which is meaningless to the client on the client to preserve some state between requests. The difference is that session id cookies are in themselves meaningless because they do not represent any meaningful information, while the encrypted cookie is meaningless because the client does not possess the ability to decrypt the data.

Encrypted cookies are fundamentally more complex: they're larger in size, they require a complex algorithm, they require that algorithm to be correctly implemented, they do contain actual data and are thereby worth attacking, they do require the management of a secret key. They're also harder to revoke due to their decentralised nature.

Session id cookies are plain simple: a meaningless random id merely referring to data stored elsewhere. The only vulnerability* is guessability, which is easy enough to prevent by increasing the length and rotating and expiring ids. I have no idea why storing session ids/data in a database would be a bad idea in any way; as long as the database is secure, there's no issue there. If your data store is prone to attacks, you have bigger issues than where your session data is stored.

(* Aside from outright hijacking, which is the same vulnerability for all cookies, and implementation specific flaws like accepting undefined session ids etc.)

Given that, you need to decide whether the increased attack surface of encrypted cookies is worth the benefits of stateless servers, and whether you trust the implementation of the encryption. For high scalability I would seriously look into it, for small-scale services I would keep it as simple as possible.


Recommended # of iterations when using PKBDF2-SHA256?

You should use the maximum number of rounds which is tolerable, performance-wise, in your application. The number of rounds is a slowdown factor, which you use on the basis that under normal usage conditions, such a slowdown has negligible impact for you (the user will not see it, the extra CPU cost does not imply buying a bigger server, and so on). This heavily depends on the operational context: what machines are involved, how many user authentications per second... so there is no one-size-fits-all response.

The wide picture goes thus:

The time to verify a single password is v on your system. You can adjust this time by selecting the number of rounds in PBKDF2.
A potential attacker can gather f times more CPU power than you (e.g. you have a single server, and the attacker has 100 big PCs, each being twice faster than your server: this leads to f=200).
The average user has a password of entropy n bits (this means that trying to guess a user password, with a dictionary of "plausible passwords", will take on average 2n-1 tries).
The attacker will find your system worth attacking if the average password can be cracked in time less than p (that's the attacker's "patience").

Your goal is to make the average cost to break a single password exceed the attacker's patience, so that he does not even try, and goes on to concentrate on another, easier target. With the notations detailed above, this means that you want:

v·2n-1 > f·p

p is beyond your control; it can be estimated with regards to the value of the data and systems protected by the user passwords. Let's say that p is one month (if it takes more than one month, the attacker will not bother trying). You can make f smaller by buying a bigger server; on the other hand, the attacker will try to make f bigger by buying bigger machines. An aggravating point is that password cracking is an embarrassingly parallel task, so the attacker will get a large boost by using a GPU which supports general programming; so a typical f will still range in the order of a few hundreds.

n relates to the quality of the passwords, which you can somehow influence through a strict password-selection policy, but realistically you will have a hard time getting a value of n beyond, say, 32 bits. If you try to enforce stronger passwords, users will begin to actively fight you, with workarounds such as reusing passwords from elsewhere, writing passwords on sticky notes, and so on.

So the remaining parameter is v. With f = 200 (an attacker with a dozen good GPU), a patience of one month, and n = 32, you need v to be at least 241 milliseconds (note: I initially wrote "8 milliseconds" here, which is wrong -- this is the figure for a patience of one day instead of one month). So you should set the number of rounds in PBKDF2 such that computing it over a single password takes at least that much time on your server. You will still be able to verify four passwords per second with a single core, so the CPU impact is probably negligible(*). Actually, it is safer to use more rounds than that, because, let's face it, getting 32 bits worth of entropy out of the average user password is a bit optimistic; on the other hand, not many attacks will devote dozens of PC for one full month to the task of cracking a single password, so maybe an "attacker's patience" of one day is more realistic, leading to a password verification cost of 8 milliseconds.

So you need to make a few benchmarks. Also, the above works as long as your PBKDF2/SHA-256 implementation is fast. For instance, if you use a fully C#/Java-based implementation, you will get the typical 2 to 3 slowdown factor (compared to C or assembly) for CPU-intensive tasks; in the notations above, this is equivalent to multiplying f by 2 or 3. As a comparison baseline, a 2.4 GHz Core2 CPU can perform about 2.3 millions of elementary SHA-256 computations per second (with a single core), so this would imply, on that CPU, about 20000 rounds to achieve the "8 milliseconds" goal.

(*) Take care that making password verification more expensive also makes your server more vulnerable to Denial-of-Service attacks. You should apply some basic countermeasures, such as temporarily blacklisting client IP addresses that send too many requests per second. You need to do that anyway, to thwart online dictionary attacks.


nmap output to file different than interactive output?

You used the -T5 option, which according to the documentation does the following (emphasis mine):

  T5 does the equivalent of --max-rtt-timeout 300ms --min-rtt-timeout 50ms --initial-rtt-timeout 250ms --max-retries 2--host-timeout 15m as well as setting the maximum TCP scan delay to 5 ms.

The important point is that host timeout. That says, "If you spend more than 15 minutes on a host, stop and give up on that host without showing output." Several users have requested that Nmap show partial results in this case, but nobody has contributed code to do so.

You have a couple of options if you want to get output from these hosts:

Use a less-aggressive timing option. You could use -T4 which has no host timeout, or use -T5 and override the host timeout: --host-timeout 24h for example. There is not currently a way to turn off the host timeout entirely once a timing template sets it.
Scan less stuff. You are using -p - which scans 65535 ports. For a host on a LAN, that's not too much. But your output says the latency is 0.17s, which is slower than I get from the middle of the USA to London. It is reasonable to expect that hosts at that distance may drop a packet or several, leading to slower scan times.


Passing data among 3 parties with public key encryption

If it isn't required that you can decrypt the customer ID, then I believe that you can use an HMAC. You create a shared secret between C and P. This should be a really nice long shared secret. When you go to store a customer ID you store HMAC(SECRET, CustomerID). When C wants to look up a record it performs the HMAC and passes the result to B who can do the DB lookup.

You are protected from pre-computation attacks because you have used a very long shared secret (let's say 1024 bits but less may be secure - others maybe can help you).

Likewise, the long secret protects you from brute-force attacks.

I believe that this securely satisfies (1), (2), (3), and (4). Of course, if you need to be able to go backwards from the hashed ID to the actual ID, this doesn't work. I know that you don't specify that requirement in your question but maybe you assumed it was obvious.


Can any ECC field element be safely serialized as "compressed" and then restored as uncompressed?

Point compression does not lose information; that's the point.

Technical details: suppose we are working in field Zp for a big prime p. The curve equation is:

Y2 = X3 + aX + b

for two constants a and b which define the curve. For a point (X,Y) on the curve, you can use the equation to recover Y2 from X alone. Since we are working in a field, Y2 can have at most two square roots, and they are opposite to each other (that's Y and -Y). Since p is a big prime, it is odd, so Y and -Y always differ in their least significant bit, except if Y = 0, in which case -Y = 0 too. Therefore, knowledge of X and the least significant bit of Y is always sufficient to unambiguously recover Y, at which point you have the full point.

(Moreover, you normally choose your curve so that it has a prime order, which indirectly implies that there can be no point on the curve such that Y = 0. But even if there is such a point, then compression still works.)

A similar mechanism works for binary curves (when the field is GF(2m) for some integer m) but it is slightly more complex to explain (it involves computing half-traces).

Be wary, when uncompressing, to make sure that you get a valid point. If the computation yields a value "Y2" which is not actually a square in Zp, then decompression will fail, but some square root functions won't notice it. Unwanted behaviour on abnormal data is a classic source of security weaknesses; such is the subtlety of practical crypto.

There are some rumours that point compression would still be covered by some patents, which explains why opensource library developers don't rush to implement it. Whether the rumour is true, though, is another story. This Wikipedia page lists two patents, one from Certicom (but it is about binary curves in GF(2m) only, and it is due to expire on July 29th, just five days from now), and another from HP (that one purports to cover point compression in general, but half of it concentrates on binary curves).

I think the HP patent would not go far in court, in particular since it was filed in 1998, at which time the concept of point compression had already been published far and wide. I am not a patent lawyer, though (I am a bear with a fake name).


Purpose of certificates signed and trusted by CA

— Hello, I'm Facebook. Trust me, now type your Facebook password.

Ok, so you have the public key of a website. And that website declares that it is Facebook. How do you know that this is really “the” Facebook, and not some Facebook impersonator?

When your browser visits https://www.facebook.com/, it retrieves not just a public key, but a public key certificate. Rendered in English, that certificate says roughly (in a way that is cryptographically verified):

I call myself facebook.com, and this is my website.
Verisign has verified that I have some right to the name facebook.com.

Verisign is a certificate authority. Its role is to ascertain that the public key is really Facebook's. Facebook obtained this certificate by proving that they had access to the private key and showing some kind of proof of identity to Verisign.

Your browser or your operating system is preloaded with a short (a couple of hundreds) list of certificate authorities. It trusts these authorities to verify the identity of websites. Your browser could not realistically be preloaded with the ever-changing millions-strong list of websites. Nor would it be feasible to verify out of bands (how, anyway?) the identity of each and every website you access over HTTPS.

Certificate authorities are one of the ways to set up a public key infrastructure. There are a few parties (the CAs) that everybody knows; you get to know other people because CAs have given them identity papers. Identity papers, by the way, are a non-cryptographic form of web of trust: you trust that this guy over there is really John Smith because his government-issued passport says that he's John Smith.

The main alternative to CAs is a web of trust, where everybody knows a few other people, and you try to establish a path from yourself through who you know to who you want to talk to. It doesn't work well on the web because people typically want to access websites that they just discovered via Google, they don't want to spend a lot of time and energy verifying some mumbo-jumbo certificate.

Note that the description above represents the theory. In practice, as always, things can go wrong, especially CAs botching the verification. But most of the time — enough of the time to be useful — the CAs serve as roots of trust for website identities.

Follow-up reading: Certificate authorities for a PKI


Government/ISP tracking of internet activity trivial to evade?

Your question deals about valuable targets which means that the services already know he is a terrorist/criminal. Then, I won't speak about « finding » them.

Using a VPN does not necessarily protect the target. Indeed there are 3 weak points :

The VPN does not change DNS thus the target has its trafic encrypted but the ISP can still see every domains he is visiting. This is called dns leak.
The VPN changes DNS but (and i'v seen that) use some non-privacy friendly one like google for example. If you have ever heard about PRISM then you'll understand the change is useless.
The VPN provider will/has to handle info on the target. Either it is forced by law or it accepts demand from those services. Keep in mind that the provider will have your real ID, payment info etc.. and can see your trafic. (Assuming you're not using a token based VPN) You should not believe any service that pretend to be "NSA Proof" or that don't keep any logs. There is always trust somewhere for the average consumer. (--> 'Hide My Ass' and LulzSec).

Proxies will be useless. At least for the average consumer. Keep in mind that those services are tapping fibre-optic cables. The target could use Tor but this is link with my next point.

Setting up a VPN/proxy/Tor on your computer does not make you untraceable. The target will have to follow strict rules and not make any mistakes which means never do anything that could help to correlate his real ID and the one browsing through his anonymizing solution. I won't even be able to list all the possible mistakes that people did: open pdf documents while connected, browse with Tor while your usual browser is still open, set up a VPN after Tor or a non-trusty one before Tor, browse Tor at home or never change the location… Well there are lot of points when the target is “playing with his life” against persistent threat which are able to manage 'attack' against Tor network.

You can have a look at some documents Ed Snowden leaked or even go on wikipedia. They should be able to decrypt a lot of VPN traffic. It is not on real time but is useful in a lot of cases. Tempora is definitely something you should dig in.

You ask only about internet but there are still a lot of communications done via mobile phones. Both NSA and GCHQ have been said to monitor those. Does the target is encrypting his phone calls and SMS? If not an IMSI-catcher will be useful.

Last point is about compromising devices. Phones should be the most breakable devices. Again an old article.
The point in computer security is that no system is 100% secure. It is until we find the breach. And you can be sure those services have guys working on that every day of the year. No matter what anonymizing solution you are using, if your device is compromised it's over. A simple keylogger would give those services every information they want.

You should also get informed about CISA. A really nice bill coming from US.

For a conclusion I would say that those services will most likely use mistakes and misconfigurations from users to spy on them while gathering maximum data from providers/companies in a legal or illegal way. Using known or unknown security breaches will help them to compromise devices.

To end, I would say that your question silently implies that those "spying laws" emerging in a various range of countries around the world are effectively set up to counter terrorism or criminal activities. Well, one could see that these are just a way of setting a global surveillance on people that effectively don't know how to protect themselves. We already know that mass surveillance is not necessarily helpful in the fight against terrorism.


Can you write OS-related virus using high level languages like Python

Yes, malware exists in all sorts of languages. Often, though, some of the most critical fiddly bits of many exploits are written not in C or C++, but rather directly in machine code, carefully assembled often by hand. This may be the only want to get the sizing and alignment correct for what you're trying to do.

The distance from the "metal" is a matter of abstractions and assumptions.

Writing in machine code uses no abstractions and creates no assumptions.

Writing in assembly provides some level of abstraction, but now you're dealing with the assumptions made by the assembler. So code might not be aligned like you want, but the instructions will be predictable.

Writing in C adds another layer of abstraction, but now you're limited to the sorts of assembly code that the C compiler will produce.

Writing in C++ adds quite a lot of abstraction, particularly with respect to memory management and function calls. Now your code might be rearranged a bit, and you may get more code in your binary than you actually wrote. Depending on your target, this is typically not a problem, but many programs (famously the Linux kernel, but also others) avoid C++ because they don't want any unpredictability.

Writing in Python changes things pretty significantly. Now you're not even producing machine code, you're producing instructions for an interpreter. How the code executes depends on the version and build of the interpreter installed, and your assumptions have to be tuned accordingly. You can only use it where a python interpreter is installed, and only in contexts where python can be invoked.

You use the tool for the job. Many exploits involve even Bash code, which is far less capable than Python, but it's simple and it's available. If you really know what you're doing, then this isn't even a question worth putting a lot of thought in to; you use the tool that gets the result you're looking for.


Hashing speed with true random passwords

If users could be relied upon to provide truly random passwords, there would be no need to use a slow hash function.  But you can never rely on users for that.


User Credentials for Accessing Network Resources

The Kerberos authentication plugin we found for RabbitMQ is immature and isn't being maintained as far as we can tell. The only real option was for us to send the user's credentials to RabbitMQ over a TLS connection. We store the credentials in the app in a NetworkCredential object as needed which encrypts the password in memory making it significantly harder to gain access to.

Application users and power user credentials are only viable when you can control access to those credentials. That is, they should only be used in limited contexts, like within a secure web application or service that itself controls access to specific functions users can perform. The app, living on a server, can use the elevated account, without exposing the credentials to a user.

If you share power user credentials with common users, through a desktop app for example, so that the user can take actions that the power user can, then you have to assume that the user has those credentials now, no matter how well you obscure those credentials inside the app. It's a better idea to use the user's own identity for security whenever possible. This allows you to revoke permissions from a user if needed. It also allows you to track and log who is doing what in the system.


Given current technology, no, I don't believe this is at all practical. The problem is there is a lot of EM out there and you would need a way of being able to make sense of all that noise. The techniques you refer to normally require close proximity to a specific target and the technique normally needs to be tuned to that particular target because different types/brands/models of electronic equipment have different EM signatures.

Think of a busy room full of people talking. You can't easily hear and understand all those conversations - they are just noise. However, if you focus on a specific conversation, then you may well be able to pick up understandable content. However, you will be limited to those closest to you - it isn't easy to filter out all the closest speakers and just focus on someone across the room. If you wanted to pick up all the conversations, you would need to have nearly as many people as conversations and theyw ould need to be spread throught the room. So, you would need lots of resources and then, for this information to be of any use, you would need to post-process the data you collect.

Of course, this doens't rule out someone finding a way in the future where they can isolate the signals and increase the distance you are able to pick up the signals - so it may be possible in the future, but I don't believe it is practical now.


Basically that techniques tries to test the reordering mechanism in TCP, you can see the problem as a linked list that needs to be in order, so depending on the implementation of the TCP stack this can be a problem or not, also take into account that the IP packets that are part of this list needs to be in memory until the last TCP PUSH Packet that in general is the indicator that the segment is complete. So two problems here, the first related to the implementation of the list and the second a problem related to memory because you need to keep the packets on memory until the PUSH or close the connection happens. Hope it helps to clairfy


Yes, a VPN would mask your HTTP requests as they would be routed through the tunnel. Unless your ISP is somehow exploiting a weakness in the VPN protocol and decrypting the traffic, they would not see the requests.


truecrypt volume - Recover 18char known password with hashcat (characters variations)

There's currently no hashcat-native way to process a list of rules that perform both one-to-one and one-to-multiple character substitutions to attack TrueCrypt at efficient speeds. Because TrueCrypt is a pretty slow hash, you might be better off performing the substitutions using an external program, and then piping the results to hashcat. (In other words, the overhead of generating candidate passwords yourself won't bottleneck the cracking process.)

Your other options using hashcat directly are as follows. They all have trade-offs.

To replace single characters with other single characters, you can use hashcat's built-in rules system - either by making your own rules, or using one of the "leetspeak" rulesets in the "rules/" directory that is distributed with hashcat. To craft some custom rules, you can study the rules system and those rulesets to get the idea.

The attack would look something like:

hashcat -a 0 -m [62xx] -r rules/leetspeak.rule target.hashfile

Replacing a single character with multiple characters -- your 'U' -> '|_|' case -- is a little trickier.

For general purposes, there are options:

Mapping single characters to multiple characters is supported in what is now called hashcat-legacy (CPU only), using what is called a table attack. However, hashcat-legacy does not support Truecrypt hashes, so that won't work for you.
A similar attack is possible in modern hashcat using the -j and -k parameters and what are called positional parameters in the rules system. Basically, you're telling hashcat to "remember" the position that it found a character, removing the character at that position, and then inserting the characters that you want.

The second approach is a special case of selective character substitution, as documented on the hashcat wiki. Here's the relevant part of that documentation, with the multi-character approach mentioned last:

If you only want to operate on the first instance of a character, you can use %1s, or simply use '/':

$ echo -n 'Odessa77' | hashcat --stdout -j '%1s Dp ip$'
Ode$sa77
$ echo -n 'Odessa77' | hashcat --stdout -j '/s Dp ip$'
Ode$sa77

If you only want to operate on the second instance:

$ echo -n 'Odessa77' | hashcat --stdout -j '%2s Dp ip$'
Odes$a77

… etc. Unlike the 's' rule, which replaces all instances of a character, this allows selection of which instance of a character to replace.

You can also use this functionality to replace one character with multiple characters:

$ echo -n 'p@ssW0rd' | hashcat --stdout -j '%1W DpM ip/ ip\ ip/ ip\'
p@ss\/\/0rd

Notice that the insertion is one character at a time relative to the remembered position, so the characters being inserted are listed in reverse order in the command.

Here's an example closer to your use case:

$ echo TrueCrypt | hashcat --stdout -j '%1u ip| ip_ ip|'
Tr|_|ueCrypt

The major drawback of this approach is that positional parameters only work with -j and -k, and so can only be used one at a time (for a single substitution, not part of a large list of substitutions as you are likely to want).

So that's the long story of why rolling your own character substitution method -- with, say, Python, perl, or even sed -- would be the most flexible solution (and because TrueCrypt is such a "slow" hash, generating the strings at super-high speeds isn't necessary).


Under GDPR, is one user borrowing another's logged-in session for financial transactions illegal?

Article 32 states "the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk".

If a regulator looked at what you were doing and concluded that you hadn't done this, they could certainly impose a penalty on your organisation.

Their conclusion - and the penalty - would of course be very dependant on your exact circumstances.

But off the top of my head, it looks like this behaviour increases risk to the data subjects (because fraud is more possible without a good audit trail) and that you have not implemented appropriate controls (because you wouldn't be asking us for help if HR had fired people until they stopped).


Tony Cox and Jeff Lowder have provided some excellent commentary on CVSS (Indeed SIRA includes lots of good discussion). Their goal is  bit broader than yours, but I think that the referenced article provides an index to commentary about CVSS. @Metahuman's post points out that CVSS can be supplemented.

The Department of State's iPost system  found that CVSS scoring over estimated the value of unimportant risks; if I recall correctly they simply cubed the values to emphasize the serious stuff.  State's iPost is the model (albeit a flawed model according to the Department of State Inspector General) for the DHS CAESARS - but both of those are more architectural than your goal.

CVSS is a flawed standard - I know that there are active efforts to revise/reform it.  There is considerable subjectivity in the ratings - I can't find the reference at this moment, but someone ran a test where they gave several experts the same information about a vulnerability and they used the CVSS process but came up with very different answers. But it is a standard. It is an excellent place to start for a project such as yours where you're looking for a reference standard without the effort of creating your own methodology.  You can use CVSS (and CWE) as starting points, and then do what @Colin Cassidy calls "magic maths".

CVSS is system-centric; it ignores architectural security features, and it probably undervalues vulnerabilities where the web/cloud is the delivery vector. I'd want to look at OWASP  and Veris for more statistical information about real world exploits rather than on theoretical models.

I probably wouldn't ignore the environmental metrics; indeed in the medium term, I'd use the components of CVSS to begin to roll your own vulnerability score that is more closely fitted to your needs.


If you're asking whether sensitive information is safer when sent over the phone vs. over the Internet, you're probably looking for protection at the wrong layer.

If "basic best practices" are being followed, then any sensitive information that you don't want to be disclosed to third-parties is going to be protected by end-to-end encryption during transmission. At that point, it really doesn't matter whether the data is transmitted via fax, Internet, or homing pigeon. The encryption is what you rely upon for protection - not the transmission medium or infrastructure.

To address concerns of malicious attachments via e-mail vs. fax, cryptography still comes into play. Only this time, you don't use encryption. You use digital signatures. Then you trust that the sending party won't sign a package that contains a malicious attachment. Arguably, e-mail can be differentiated from faxes here, in that even with cryptography one might still receive a malicious attachment - and it has much more impact on a computer than it does on paper.

In either case, you do need to make sure that parties on both ends have the appropriate cryptographic tools and keys available to them. Again, this goes regardless of the transmission format. You're probably more likely to be able to coordinate support for encrypted & digitally signed e-mails than you are faxes, and that is what gives e-mail a distinct leg up in this discussion.

But again, the point remains that your transmission medium should not be what you rely upon for protecting sensitive data. Protect it before it goes out of your system, and you don't have to worry about the weak link(s) - or any hawks - that may be in between.

And in the end, much of the difference can become moot anyway. What you put into your fax machine is just as likely (if not more likely) to land inside of someone's e-mail inbox these days as it is to actually get printed by another fax machine.