Some tools make a educated guess regarding the encryption and salt type but there are numerous types of encryption schemes, some so closely related that the hashes nearly looks the same.

Take for example the following hash (altered to protect the google dork): 0000000B84FF762C88DG6E16F324269EFCA186FA

If I ask a classic such as John the Ripper to crack it without specifying what type, I get the following response:
Warning: detected hash type "raw-sha1", but the string is also recognized as "raw-sha1-linkedin"
Warning: detected hash type "raw-sha1", but the string is also recognized as "raw-sha"
Warning: detected hash type "raw-sha1", but the string is also recognized as "raw-sha1-ng"

Thus, John will run and try to crack the password as "raw-sha1" but it could be wrong.

If I input the same hash into hashcat-plus, it complains about the hash length and ask that I specify a hash type. All well and good I suggest SHA1 but there are also numerous permutations available that could mean a endless amount of time wasted if you choose wrong. E.g. Hashcat gives the following options for SHA1

100 = SHA1
110 = sha1($pass.$salt)
120 = sha1($salt.$pass)
130 = sha1(unicode($pass).$salt)
140 = sha1($salt.unicode($pass))

Searched around and found some interesting tools to find the encryption type and they can be broken down into two categories namely with source / binary available and without any source binary.

Finding the encryption type through reverse engineering can be achieved via tools such as:

http://www.autistici.org/ratsoul/iss.html - A plugin for immunity debugger that identifies common encryption or encoding functions / structures etc.
http://aluigi.altervista.org/mytoolz.htm#signsrch - is the binary version of the immunity plugin version
http://www.hexblog.com/?p=27 - a plugin for OllyDbg to determine the type of encryption
https://www.hex-rays.com/products/ida/tech/flirt/index.shtml - a plugin for IDA Pro to determine standard called libraries, could be used to identify encryption libraries

Then there is the "educated" guess script:

http://code.google.com/p/hash-identifier/ is a script that compares various attributes such as length, contained char types etc to produce a possible hash type used. Seems to be included in Backtrack5 standard.

And the websites that allow for manual verification such as:

http://www.insidepro.com/hashes.php - Allows you to enter a password and compare the hash to your example hash
http://forum.insidepro.com/viewtopic.php?t=8225 - Lists various encrypted hashes to allow for a manual comparison

So basically it seems that without prior knowledge of the hash used, with no source / binary available to reverse engineer, you are basically left with serious guess work. And to add a little pressure, choose carefully since choosing the wrong hash can lead to a LOT of wasted time!


Is it possible to communicate securely entirely over the internet given a global, resourceful man in the middle?

No, for sufficient values of "entirely over the Internet" and sufficient values of "secure." A "global" MitM could sit on everyone's network connections, and create a fake persona for everybody (cryptographic keys, signatures, message-writing patterns, etc.). Assuming no one shares anything offline or over a trusted network, you could never talk directly to any communication partner; everything would go through the MitM, which would replace everything designed to prove veracity.

You can't create trust over an untrusted connection, because you have no way of knowing that all the messages aren't coming from someone else. Trying to create trust from mathematical algorithms is not possible; it's just like trying to create math strictly from mathematical algorithms. You need to have something that is trusted automatically. The only way to actually create trust is through a judgment call.

The issue with doing things entirely online is that a MitM can pass almost everything through. Therefore, just because you get the right info over a wire, doesn't mean no one's tampering with it. You can only trust information you receive if you receive it over an already trusted connection, or if you can link it to information you already trust, or if you just decide that it's trustworthy enough (in which case no evidence supports it, and you need a good enough reason to do so). You can only create a trusted connection by somehow linking it to something you already trust in a secure way (e.g. via cryptographic algorithms), or by deciding to trust it without regard to evidence. There are communication channels that people trust without evidence: in-person communication is the primary one. People often trust government-issued ID documents, which is often used for PGP keysigning (another alternative is trusting that you can recognize your friend in person). However, if there's a global MitM, there are no automatically trusted Internet-based communication channels; if you likewise don't allow preinstalled keys or the like, there's no way to get any trusted electronic communication, which means you can't trust anything (as all communication is assumed to be over the Internet).


To use an analogy, expanding on what people have said about it being a chip:

An older style magstripe card was simply a string of characters encoded onto the card, it could be read, or written, and that was it.  It's like a page of a book, you can read it, but if you don't understand, you can't ask it questions.

An EMV chip is a small microprocessor. It runs a specific application. You can't just read what it knows, but you can 'ask' it 'questions' by issuing commands from the EMV set, and see what it returns.  Unlike Magstripe, it's interactive, and is capable of both answering and more importantly, refusing to answer queries.

All of this is a little simplified.  Encryption obviously plays a large role in EMV, and it's much complex than just some little microbug that you can interview, like I make it sound, but the essence is there.

Like @Lucas Kauffman has mentioned, EMV isn't unclonable, but it is significantly more difficult, at least if you start from first principles.  As with many security issues, these complex differences will start to mean less and less now that vulnerabilities have been found, because it will be possible to buy cloners without needing to know how they actually work.


On device tests

Check the logs off the previous batches of texts; if they came in some what regular intervals and then stopped I'd take that as a sign of automated hacking attempts. And their stopping as a sign that either; they ran out of exploits to try, or had one succeed in pwnage.
Check the time stamp of latest system update, if messages resumed shortly after an upgrade then I'd take that as a sign that it was once in a bot-net and is being re-assimilated once again.

Suggested actions

Do not respond to the number. Some automated phishing/malware deployment scripts seem to be testing for text compatibility before attempting to send payloads.
Do not plug the device into any computer; not even for forensics! I've already heard one horror story that didn't end well when an infected phone touched a PC in a USB way.
Do not allow it on your local Wi-Fi network. While I've not seen malware jump over Wi-Fi in the wild (between phones and PC that is) I've tested if possible on Android and it isn't hard.. on my own devices only (I'm not a distributor) which you can read up on it at Stack Overflow where I've detailed how to get Android running Metasploit.
Do take the device into the dealer and make them explain what those messages are. If they can't figure it out ask for their security department contact details.
Do contact the security department for the devices service provider. Ask them to either monitor the account and traffic for suspicious activity or send them the device for imaging. Their hardware is put at risk instead of you own.
Check the local laws regarding harassment. If the texts are coming in at times that are legally defined as an inconvenience then you maybe able to take this issue to government agencies responsible for enforcement and investigation.

I've experienced having to report possible security issues to two different service providers and can say that you'll need to be patient & persistent. This is because from my expenses to get in contact with both the right department and the correct person took multiple calls, transfers, and luck. Most will tell you to turn it off and back on again in which case ask to be transferred up the chain till you get someone with more that the minimum required metal capabilities to be considered living and warm.

That all being said the best course of action is to notify the service provider because not notifying them may make you partly liable for damages done to other servers or devices. Think of it like knowingly spreading an infectious disease if you don't notify them because that device is showing symptoms.

Edits & updates

Additional malware hunting options

Both Android and iPhone have an interesting bug/feature involving Airplane mode which I documented a bit at Security Stack Exchange here's the relevant quote...

  For Rooted Android (attacking/sniffing) I like InterceterNG and DSploit for intercepting traffic between another device and it's WiFi access point. However for this to work on cell phones and force all traffic through the WiFi the target should first be put into 'Airplane Mode' and then have it's WiFi turned on. Then fire up interceptor on the attacking Android device and sniff away. WireSkark helps with pcap files but if you just need IPs and packets with time stamp IntercepterNG is great on the go; it'll even try to help strip https.

... the suggested course of action was to intentionally "Man in The Middle" (MiTM) attack the device's Wi-Fi and profile it's traffic.

Note this trick with airplane mode also works for Bluetooth sniffing.


Legality of sniffing own traffic between mobile app and server

First, a definition.

  Reverse engineering, also called back engineering, is the processes of extracting knowledge or design information from anything man-made and reproducing it or reproducing anything based on the extracted information.
  The process often involves disassembling something (a mechanical device, electronic component, computer program, or biological, chemical, or organic matter) and analyzing its components and workings in detail. Source Wikipedia Reverse Engineering

So. is extracting data from a connection extracting knowledge or design information.
  The answer Yes it is.
However to be reverse engineering we need more . we also need to 'reproduce it or reproducing anything based on the extracted information.'.
And are we doing that. the answer is No. we are only checking data we receive over the line, for verification purposes. (we verify that the application is doing what it is supposed to do, not (re-)build an alternative implementation.

So. unless the legal definition in your area is different from the wikipedia definition there should be no grounds to claim reverse engineering.

Also you are not reverse engineering the software. You are analyzing the connection it uses. (even if you consider just the act reverse engineering, there is no intellectual property hat you can breach by analyzing the data on the wire. since it outside anyone's control.)

Since your just noting what you can see and not manipulating the connection in any other way you are not doing anything with the software they use. (in fact you are doing nothing more than any corporate firewall can do).

To be sure consult a lawyer, but on the face of it you should be fine.


Do major linux distributions differ with regard to releasing security patches?

Your question is a good one as it is used by some marketing department to praise their own Linux distribution.

Most often Linux distributions are not the patches authors: as their name states they are just distributing otherwise already existing content.

A security vulnerability is discovered and notified privately to the software development team,
The software team develop a fix and forward it to the main distributions (this may take a variable delay depending on the correction complexity, hopefully at this step the issue is known only by the software development team and the vulnerability discoverer),
The main distributions produce an security update, and sometimes all of them including the software author coordinate themselves to release the fix at the same time, thus maximizing the number of people getting the fix before any exploits gets developed by analyzing the fix content,
After a variable delay (most often a few days but it can be longer depending on the software development team transparency policy) the vulnerability is publicly documented so administrators can now compare the behavior of vulnerable and fixed environments and ensure all of their environment is properly fixed.

Security updates are therefore most often upstream updates that the distribution team must:

Apply, which include recompiling all required software for all supported platforms,
Test to ensure it doesn't break anything on the distribution,
Customize if the patch cannot be applied as-is, and then go again on the previous "test" step,
Release to the distribution users when the patch has been properly qualified.

The issue then with the Linux distribution regarding security updates release is not really the "enough eyeballs effect" you mention, but the number of developers available for these steps, even more since upstream security updates cannot be planned in advance and that most developers act on a voluntary basis.

Large well-known distributions will have generally no issue with this: there will always be enough people available somewhere on the planet to work and coordinate themselves in order to release the update quickly (however even then the whole process will most likely take a few days instead of the few hours you seem to expect). However for smaller distributions (or somewhat confidential derivatives from larger distributions) this may be a real issue.

So, to answer your question, any large and well-known distribution will be approximately equivalent (and very good) into their response time into releasing security updates.

However, in all cases, you should read the distribution update policy and procedures upfront:

As you mention, different distributions may have different update procedures adapted to different needs. As it appears in your question, you deem binary update to be more secure because quicker to apply, while other consider source code diffs more secure because it can be inspected.
Different distributions may also adopt different life-cycles. Some may need a full system upgrade every 6 or 12 months, no update being provided for previous versions. Some will provide updates for a longer period, covering several years, and possibly cover both the current and a one or more previous releases. Some distributions rely on a Long-Term-Support (LTS) basis: some releases are flagged LTS meaning they will get updates during a longer period than releases which are not. At last a few distributions rely on a rolling-update principle: there is a single release which evolves over time, all installed products being always at the most recent version but updates may require manual configuration changes.

This distinction is important because while a stable security update should not require any manual configuration changes after the patch has been applied, the amount of changes needed after a full system upgrade can be quite substantial to say the least. Therefore some people will prefer to keep the same version a longer time, even if they do not benefit from the latest features, while other people prefer to upgrade to the most recent release in order to benefit from the latest features, even if this require more work (this will be the case mostly only for individual users, corporate users will usually go to the longer support period).

However, if you need serious guaranties (like an insurance for your business), then you should choose a commercially supported Linux distribution where:

Update delivery will not rely on benevolent work any more but on paid employees,
Your Linux distribution provider will be accountable to you in case of issues,
You will benefit from professional support to assist you for the update application (it is good to have a security update available, but what if it breaks your environment?).


What's the concrete case for code flow being more secure than implicit flow?

1st question: it mitigates attacks described in OAuth 2.0 Security Best Current practice draft-ietf-oauth-security-topics-133.1.2.  Implicit Grant, mainly:
- browser history token leakage
- compromised devices where an attacker can somehow manipulate the client (such as a malicious browser extension)

2nd question: the client will necessarily have to use the acces token. In the authorization code flow, however, the access token doesn't go through the web flow which helps with mitigating attacks on the web stack. On the contrary, it exchanges the authorization code against tokens on the /token API direct. Moreover, use of PKCE prevents an attacker from using an authorization code intercepted in the browser or on the host application (eg. on mobiles, by claiming the redirect URI which cannot be owned by a single application).


Can the new WannaCry affect Linux ext4 file system data from Windows?

There are different variants circulating but some can. Once infected it damages/modifies the master boot record prior to windows even being loaded, then yes it can. Once it does, then it attempts to encrypt the full disk.


ssh/scp from server to server -- set permissions (no root)

If your server B has fuse and sshfs installed and both servers are permanent (fix ip, 24/7) your best choice is to user-mount the other server's directory and copy files over that channel.

On serverB:

$ mkdir $HOME/serverA
$ sshfs youruser@serverA.domain:restricteddirectory serverA

from now, your scripts on serverB can copy files into $HOME/serverA. This is reasonably secure solution. Since the channel is set up manually, no password, no unprotected key-files can be stolen. Furthermore the possible attacker will be unable to escape from restricteddirectory on ServerA. All goals are reached. The backside is that you have to remount the directory every time  (either) server reboots. In enterprise environment this might be a minor problem, and you can set up a script/cron to check the connection and send you a mail if the other side is unavailable (so you can log in and fix the problem).

If the server has dynamic IP or offline often this approach won't work. Using automated scripts for accessing serverA will require you to store your password or unprotected priv-key on serverA, therefore there is no way to prevent successful attacker of serverB to reach serverA with your privilege level. (However this absolutely doesn't mean that (s)he can "hack Server A". You are unprivileged user. But your account will be compromised for sure).

In fact, you might try to fiddle about screen and ssh-agent to avoid storing credentials, but you will face one of the problem before, if serverB reboots you have to login and fix things.

The only truly secure solution which comes into my mind in this case to use some intermediate storage. Set up an account at a third place (serverC), restrict access to serverA and serverB's IP address and you can proxy all data easily. At serverA your pull scripts will get the data. Because you never access serverA from serverB, your account cannot be hacked even if serverB silently compromised at root level.


Google Chrome Linux with Activity of Unknown Device

I assume you mean that the unknown device has your same home IP address -- so, not 192.168.x.y but something belonging, say, to Telecom Brasil.

If this is the case, the problem lies not in your Chrome browser or desktop Debian distribution, but in your home or nearby. Something is accessing your GMail account from your wireless Access Point, which implies it knows the access codes for both.

The most likely explanation is that you have GMail on your WiFi-connected smartphone also.

Or you could have some "smart" device somewhere - an Android TV maybe - that's synchronized with your Google account.

Otherwise, it's someone else's device. This is, of course, potentially very bad. Try changing the passwords on both the account and the access point, using two different, robust, non-guessable passwords, ensure the access point is not vulnerable to some exploits (just google "BrandOfYourDevice exploit" or "BrandOfYourDevice security vulnerability"), it is not accessible from the outside, and is configured for WPA2 security.


A hash function like MD5 processes a message of arbitrary length (up to some ludicrously large maximum length, some zillions of terabytes). The raw computational cost of MD5 can be roughly split into three parts:

Initialization: set some internal state values.
Data processing: mostly proportional to the input length.
Finalization: the "closing computations" of the hash function, yielding the final output (things like padding occur at that step).

OpenSSL, in its benchmarks, measures the speed of doing the three steps with messages of various lengths, so that you might somehow infer the cost of the data processing and the cost of the two other steps.

However, such benchmarks are meaningless because they measure the code performance under unrealistic conditions. When OpenSSL runs, it goes into a tight loop, hashing millions of messages in a row: this ensures that the hash function code itself is in L1 cache, that branch prediction in the CPU is fully aware of the probable direction of each conditional jump, and that the input data is also in the CPU L1 cache. None of this really applies to a practical situation.

In practice, I/O and RAM bandwidth costs will dominate, especially with "fast" hash functions like MD5; also, the hash function is not alone in the data path, and other tasks will matter. For instance, in your code, the call to strlen() will not have a negligible impact when compared with MD5 (it will be faster, but not to the point of not even showing up in measures).

What you should do is to measure performance of your complete system, not the hash function alone; and do that with a few select hash functions: this will use the actual execution context. Also, it is improbable that the hashing cost itself represents a substantial proportion of your CPU.


How likely is an infection with an outdated skype on linux?

Firstly, upvote cx42net's answer, because as he says, the vulnerability only affects a certain type of package - the statically linked one.

The difference between static and dynamic linking is the use of shared objects. In a statically linked program, all 3rd party code is "baked in". If there are any vulnerabilities in it, the whole lot needs updating to fix that library.

By contrast, dynamically linked programs use shared libs which can be updated independently (e.g. by your distribution) and thus fixes in third party libraries are handled by your distribution as soon as possible, and apply to all  software run post update (because running applications will have the old SOs mapped into memory).

How do you tell which you have? The unix file command will tell you:

$ file /usr/bin/skype
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

If you see that, you're okay. It is highly unlikely you're using the static version from a debian repository - that just wouldn't make sense from a distribution point of view (the whole point of using static linking is to get around incompatible shared libraries - whereas if you have a repository, you can set dependencies on compatible libraries and kernel versions and make the download smaller to boot).

  noticed some crashes of the skype client and think that there could have been attacks on the vulnerabilities.

I'd be more inclined to put that down to the beta status of the software - although you're right to be cautious and investigating your system will not hurt.


Is it possible to browse/access the files on a computer's hard drive by booting from an OS installed in a flash drive?

In general, yes, booting from a flash drive gives you access to anything that's not encrypted.

In this specific case, Tails itself is stopping you. It's voluntarily respecting the permissions declared by the filesystem on the hard disk. This isn't intended to prevent you accessing private files though - it's simply a side effect of the fact that Tails, for security reasons, doesn't give you root access by default. You can lift this restriction by setting an administration password in the Tails startup dialog, then you should be able to access those files as root.


What is the exactly mean of these CPE file fields?

cpe-lang shows if are other dependencies for the vulnerable product. If you look over the NVD CVE's you will see some products are vulnerable only on some specific platforms. For example

<cpe-lang:logical-test negate="false" operator="AND">
<cpe-lang:logical-test negate="false" operator="OR">
<cpe-lang:fact-ref name="cpe:/o:redhat:enterprise_linux:5.0::desktop"/>
<cpe-lang:fact-ref name="cpe:/o:redhat:enterprise_linux:5.0::desktop_multiple_os"/>
<cpe-lang:fact-ref name="cpe:/o:redhat:enterprise_linux:5.0::server"/>
<cpe-lang:fact-ref name="cpe:/o:redhat:enterprise_linux:5.0::virtualization"/>
<cpe-lang:fact-ref name="cpe:/o:redhat:fedora_core:core_5.0"/>
<cpe-lang:fact-ref name="cpe:/o:redhat:fedora_core:core6"/>
</cpe-lang:logical-test>
<cpe-lang:logical-test negate="false" operator="OR">
<cpe-lang:fact-ref name="cpe:/a:xen:qemu"/>
</cpe-lang:logical-test>
</cpe-lang:logical-test>

<vuln:vulnerable-software-list>
<vuln:product>cpe:/a:xen:qemu</vuln:product>
</vuln:vulnerable-software-list>

What all that means? xen:qemu is vulnerable only on redhat:enterprise_linux::* and Fedora core* . So if you parse this xml and get only the vuln:product, for some products, you are inaccurate.

cpelan stands for - CPE language matching algorithm and was created by NIST.
Here you will find more informations: https://cpe.mitre.org/specification/


SSL certificates have an extension field that defines what a certificate is allowed to be used for.

When you buy a certificate from VeriSign with your certificate signing request, it typically will not include the extension permission for signing downstream certificates with your certificate; especially for any domain you don't have authority for.

Take google.com for instance (root to leaf node):

Equifax Secure CA - Root CA (hence implicit downstream signing authority)
GeoTrust Global CA - Has Certificate Signer property
Google Internet Authority G2 - Has Certificate Signer property but can only sign leaf nodes
*.google.com - Wildcard domain certificate with no authority to sign other certificates.

The browser checks validity from the root to the leaf. Any authority claimed by a leaf or intermediate certificate is assumed to have been authorised by the certificate that signed it; eventually culminating in the trust given to and from the Root Certification Authority.


How difficult is it to modify AES ciphertext in a meaningful way

If the padded plaintext fits into a single block, then editing it in a meaningful way without knowing the key ought to be pretty darn impossible -- in the technical sense that being able to do that (even just some of the time) would count as a full-scale break of AES.

In other words, single-block AES encryption is self-auththenticating to the exact degree that the space of valid plaintexts is small compared to the space of all possible blocks (assuming that the recipient actually verifies that the deciphered block is valid). It does not matter whether the valid plaintexts are mostly similar or look very different; all that counts is only how many of them there are. This is because AES, like any other good block cipher, is supposed to behave like a pseudo-random permutation of the space of all possible blocks.

This of course ignores the possibility of higher-level protocol attacks, such as tricking the recipient into accepting an block that was already encrypted separately (say, for a different run of the protocol).

Once your plaintext is longer than one block, using ECB makes it trivially easy to mix and match between pieces of separately encoded messages at block boundaries. But this is a property of ECB, not of AES in particular. No halfway serious application should use ECB for data that are not strongly known always to fit in a single block.

In your example it sounds like it would be a lot more relevant to attack application A directly than to attack the communication between A and B. For example, if application A runs on a device or account that the user controls, the user could likely modify the data before application A even encrypts them, and/or inspect the (running?) application to extract the key.

Alternatively, it sounds like the protocol you're sketching would likely be vulnerable to replay attacks, without bothering to edit any messages. This means that an attack on the TLS transport (such as by tricking the client end into trusting a CA root that you control) could be escalated into an attack on the authentication part -- i.e. the additional encryption of the credentials may give much less additional security than the designers intend to.


The simplest CSRF vector would look something like this:
<img src="https://example.com?send_money_to=myself@me.com&amount=100000">

Then you just need to get this bit of HTML in front of the victim.  However this will generate a GET request.  If the endpoint uses POST you could try something like (example only - not tested):
<form action="https://example.com?send_money_to=myself@me.com&amount=10000" method="POST" onload="this.submit()">
</form>

Unfortunately that will only get you GET/POST.  To submit a DELETE request you need actual javascript.  In general you could just host code like that on any website anywhere, so you don't need an XSS vulnerability.  CORS would block the javascript on your page from reading the response, but as long as the request is sent it won't matter.  Unfortunately things get more complicated for a DELETE request because it is a non-standard request and triggers additional CORS behavior.
If you try to send a cross-domain DELETE request via Javascript from a cross-domain origin, the browser will first send an OPTIONS request to ask the server if such a thing is allowed.  Therefore, as long as the destination server is properly checking the HTTP verb, it will never accept your request.  The server will respond to the OPTION request, it will not have white-listed the domain your Javascript is hosted on, and a DELETE request will never be sent.  As a result, a CSRF token is not strictly required in this circumstance.  However there are a few things that can change that:

If the server has misconfigured CORS that responds to the browser and allows all domains in the wrong way, your DELETE request will fire anyway
If your javascript runs on the actual domain, then CORS won't happen (but that would be an XSS vulnerability, which beats CSRF anyway)

In short, this would only be vulnerable in the light of additional misconfigurations.  It still isn't a great idea, because someone down the line may decide to convert all DELETE requests into POST requests, and forget to add the CSRF check, but it is probably safe as-is.


Security vulnerability of voice authentication in phone services

This is relatively old but we once tried to record my friend's voice and play it as an authentication for his voice detection mechanism.
We were able to fool it only 1 time out of 5.

Also, we made him speak the authenticating words again when he was talking to someone else and caused him to unlock the phone. The attacker was standing just next to him with the phone mic pointing to the victim. Tried this only once

You can test them on your phone.

Other test cases to consider:

If your voice goes bad because of some reason, how does it react.
Changes in voice tone and their effect


Is there a way to mimic http request of a compiled program?

Yes, it's possible and it's trivially easy.

You can make it a bit harder by using HTTPS and a pinned certificate but that will not stop anyone with a bit of time on their hand (they will then need to modify your executable, or, at least, the container where you placed your pinned certificate) and it will make it harder to manage your server (because if you need to change your certificate, you'll need to update your clients as well).


To what extent are countermeasures against side-channel attacks effective/ used regularly by everyone?

is it true that most of them do not offer absolute privacy, but rather they only reduce risk?

No, many of them completely eliminate the risk. Using constant time implementations of algorithms and not branching on secret-dependent conditions ensures that secrets being processed provably have no effect on timing, making such side-channel attacks impossible. Some cryptographic algorithms, like Ed25519, are designed to make implementations with comprehensive side-channel resistance in mind possible and practical. In other cases, the hardware itself is designed to make side-channel attacks difficult to pull off. AES-NI in many modern x86 processors is one example of that. It is an instruction set which provides acceleration for AES encryption and additionally runs in constant time.

  Are there any absolute solutions to any existing side channel attacks?

For some classes of side-channel attacks such as those based on timing, yes. See above. For the more advanced attacks that involve things such as differential power analysis, there is very often no way to completely avoid them, short of using specialized microprocessors designed specifically for security, such as those used in Hardware Security Modules (HSMs). Cheap consumer electronics are unlikely to take such measures as they bring the base manufacturing cost up.

There are a large number of different side-channel attacks. Generally, they fall into three categories:

Attacks which are done by executing code on the same system upon which secrets are being processed. These attacks include timing attacks and cache attacks and can be done remotely and without physical access if code execution on the target device is possible. Mitigation involves secure software design. This is the easiest attack to pull off, and the easiest to mitigate.
Attacks which require passive monitoring of the hardware. Differential power analysis and thermal imaging attacks fall into this category. It requires physical access to the target device and often very specialized equipment, but can be done even without code execution on the target.
Fault attacks where errors are triggered in the device by doing things such as feeding an IC with the incorrect voltage or an unstable clock in a process called glitching. Even side-channel resistant software can be vulnerable to this. Sometimes this can even involve physically removing the surface of a chip and shooting it with a tightly-focused laser to trigger faults. The results of these faults can sometimes be detected through side-channel attacks. This often results in physical destruction of the device and, naturally, requires physical access.

Mitigating the first is usually possible to do cheaply in software. Mitigating the second may or may not be possible in software depending on the actual attack, and mitigating the third is rarely possible in software, although fault attack-resistant software can be designed with sufficient expertise.

  Since these countermeasures are not widely known to the general public, is it true that people may not employ those measures. Is it also true that most consumer standard devices usually don't have these measures built into them?

It is often true, especially when the product does not use an established and popular library like OpenSSL which provide these mitigations and instead attempt to design it on their own. Those devices are often highly vulnerable to side-channel attacks, and abusing those weaknesses can be practical.

Unfortunately, the only cases where standard consumer devices do use such mitigations is with DRM in order to prevent their users from jailbreaking their own devices or running their own code on them. Companies which do that naturally care more about avoiding piracy (at the expense of restricting users' freedom) than about security against malicious attacks. This is because, in their threat model, the adversary is you, the device owner, not someone who is out to get your private information.


Try heuristic scanning tools. It's basically putting it all in a sandbox and watch it do it's thing. IF you're adventurous an technically inclined, you also can scan it with forensics tools and get that data visible for inspection. I found a cool book in google books here. If that's too long winded, you could just turn off data execution on your box and any auto run features. This would give you the breathing room to scan the file before deployment and use. Now, let's say you're one of those really paranoid types. Well, get yourself virtualbox, configure a guest, slap on deepfreeze, secure it and tweek it.


How can I detect an infection in a database?

This question is rather generic and I can't suggest a specific solution without more specific context as to what kind of web application and database you are operating on.

To detect a breach of integrity of a RDBMS (think MySQL/Postgres) table that you don't expect any updates or new entires on, you can parse the query log for INSERT, UPDATEs to that particular table. This doesn't scale in the end. I'd rather suggest you to setup some triggers to log for certain conditions (INSERT, UPDATE, ...) on tables that is reflected on your site. There is a good guide on how to achieve this with OSSEC HIDS and a custom UDF log function on https://blog.rootshell.be/2011/01/07/auditing-mysql-db-integrity-with-ossec/.

As for post-mortem/forensic examination after a breach to find particular entries that might contain Stored XSS, you'd have to look at how your data is structured and try to find anomalies rather than specific strings as XSS comes in many variations and depend on your server-side technologies, different evasion techniques used by the attacker etc.

I understand that your question is specific to databases, and post-breach examination. But best-practice is to monitor and catch these at a way earlier layer, such as some WAF/content filtering before even hitting your application such as ModSecurity[1] or IronBee[2].

[1] https://www.modsecurity.org/

[2] https://github.com/ironbee/ironbee


Can I store following holder data according the PCI DSS v3:

In short: Yes, you may store all of that data, without encryption, under the DSS, as long as you're not storing the PAN (the credit card number).

However, some of that information falls under the PII regulations of various states, and your failure to protect it would be subject to various fines.  So just because the DSS doesn't care doesn't mean you shouldn't.

In detail:

The DSS 3.2 states (emphasis mine):

  PCI DSS also applies to all other entities that store, process or
  transmit cardholder data (CHD) and/or sensitive authentication data
  (SAD)

CHD and SAD are defined as follows (also in DSS 3.2):

While cardholder name and expiration date are listed under CHD, the following caveat states that they are only considered CHD in conjunction with the PAN (emphasis original to the DSS):

  The primary account number is the defining factor for cardholder data.
  If cardholder name, service code, and/or expiration date are stored,
  processed or transmitted with the PAN, or are otherwise present in the
  cardholder data environment (CDE), they must be protected in
  accordance with applicable PCI DSS requirements.

By implication, if the PAN is not present, then the other listed data fields do not need to be protected as per DSS requirements.

Finally, while these quotes are from the DSS 3.2, they're largely unchanged from 3.0/3.1 and 2.x (to the best of my recollection; I haven't doublechecked).


What configuration will allow another computer in the internet to probe my computer's ports?

According to ye olde standards, a computer would respond to every connection attempt with, typically, one of three responses:

Application banner indicating that a service is listening and which service
ICMP Port Unreachable - indicates that nothing is exists on this port
ICMP Administratively Prohibited - indicates that your system is not allowed to access this port

By those rules of etiquette, one would expect firewalls to respond with the 3rd kind of message. However, nowadays one typically expects firewalls to drop packets without sending a response. This is what Gibson is referring to as "stealth mode".

Unfortunately, the Shield's Up website is fairly dated. The advice and analysis makes assumptions based on the late 1990's Internet. At that time it may have been a reasonable assessment, these days I wouldn't give it much credence.

A host based firewall has been included and enabled since Windows XP SP2. So, whether you realize it or not, you do have a firewall running. However, the more likely culprit is your home router. Those require special configuration, called port forwarding, to pass unsolicited traffic from the Internet to your computer.


How can log poisoning be successful with a Local File Inclusion attack?

Perfectly legal and smart attack.

You're question really boils down to "how does this work when logs are by default not readable by the webserver?".

The fact is that many webservers are set up with custom log directories where the access control is not necessary enforced. This happesn more often than you would think. In some cases the access control for the log files is wide open because sysadmin needed some other system to read them, and he just opened it up for all processes.

This can also be used to execute code from other log files like from the SSH auth log. More on this here: http://lanmaster53.com/2011/05/local-file-inclusion-to-remote-command-execution-using-ssh/

Basically it boils down to wrong permissions on the files. Even so its a good attack which is very relevant.


apt-get install dns-root-data works on Ubuntu, at least in 16.04 and up. It also works on recent Debian.


CN and SAN both matter, as there are RFIs that require identifier matching. For example, for TLS RFC 6125. So be deliberate with these. For other fields it matters less, so just copy what you have in your old certificate.

Before you generate CSR, I recommend verifying that you have 2048-bit or better key. You can do this by running:

$ openssl x509 -in public.pem -text -noout | grep "RSA Public Key" RSA

Also, consider including basicConstraints and extendedKeyUsage extensions.


I cannot give a source nor which ISP this concerns since someone accidentally crossed their NDA by telling me this, but I think it should be known that there are ISPs that, at least in the Netherlands, log all DNS requests. This would mean that any hostname you ever looked up will be logged, including google.com, regardless of whether you really connected to the associated IP addresses. It is very reasonable to assume that a judge might find it convincing evidence that you really did visit the website. (Sidenote: DNS traffic that was merely passing through, not actually directed at the ISP's own DNS servers, was probably not logged, though this is not certain.)

The ISP in question tried to log as little as possible simply because it costs them money, but they are required to do this in order to comply with the law in the Netherlands. They (nor any other ISP) don't mention anything at all about what kind of data they log, they merely tell you in the terms of service that they log "as much as required by law".

I never thought they would log each and every DNS request, and I'm fairly sure that people here also wouldn't like it if they knew that they are indiscriminately being tapped 24/7. On Google I can't find any mention of that ISP doing that, nor any other Dutch ISP, so I'm not sure this information is public. I myself knew such information had to be logged about phones, the law is very clear in that sense (it mentions exactly which data needs to be logged), but logging DNS goes further in my opinion. Anyhow, this discussion gets political very fast.

More to the point, yes your ISP can do this and might even be required to do this by law, regardless of whether the police (or intelligence agency) placed a tap on your connection. In the Netherlands ISPs are required to store the logs for 6 months, but this may vary per country.

They can also, though probably not legally or without telling you, tap your connection's contents. This means not only which domains you looked up or which IPs you connected to, but also the data that was sent to them. This usually only happens in the event of a tap, or possibly when they themselves detect some sort of abuse. It might also be that they automatically process all data in search for keywords or certain protocols, such as bittorrent handshakes or Tor traffic. However legal or not, they have the technical capability to do this without anyone knowing.


How can I protect myself from this kind of clipboard abuse?

You might have guessed this, but never use the terminals pasting functionality to paste things into vim/emacs. It's like sending a batch of commands to the editor, that can do anything.

For these reasons, editors have their own copy-pasting functionality, which cannot be injected. For instance, in vim, you should use the + register to exchange data with the system clipboard ("+p for pasting).

Regarding the shell or other terminal applications: It has been established, that you must not paste unsafe data into your terminal.

There is a safe-paste plugin for zsh, which prevents code from actually running when pasted, but someone has already exploited it anyways.

Also, a similiar question (about accidental pasting) has been asked on apple.se. Most of the solutions might also work for you.

Update: In vim, if set mouse=a is used, pasting with the middle mouse button is safe. You can still paste with shift-Insert though.


Is securing Apache with SSL certificates enough to protect all of the underlying applications?

SSL/TLS is only used to protect the transport of the data between client and server. It solely protects against sniffing or modifying these data during transport. It does not protect against any attacks which do not require sniffing or manipulation of the transport, i.e. attacks like CSRF, SQL injection, password guessing and many more.


Is it permissible to use GPG without an encryption key?

It is entirely acceptable to forgo creating an encryption subkey, if you do not wish to use GnuPG for encryption. There is no technical reason why this would be impossible, problematic or otherwise out of the ordinary. The OpenPGP standard is designed for encryption and/or signing, and quite a few people use it only for the latter. This is especially common when someone is posting to a mailing list or a public forum, as there is no one intended recipient, but cryptographic authenticity is still important.

The OpenPGP standard lacks forward secrecy because it is fundamentally impossible to do correctly using a protocol for asynchronous, indefinitely-delayed communication. There are tricks to get the same benefits as forward secrecy to a limited extent, such as by using short-lived subkeys and destroying them after use. There is also a draft extension for providing forward secrecy in OpenPGP.

The primary reason that forward secrecy is difficult to achieve is because it requires using ephemeral keys that are only kept as long as they are needed. In the case of a asynchronous email exchange, someone would need to give you their public key and you would need to encrypt with it and send them the reply. They would then destroy the corresponding private key immediately after using it to decrypt your message. The problem with this is the fact that they don't know when you're going to send a reply. They can't just keep the private key in memory only, or shutting down the computer would render any message you encrypt useless. They can't store it on disk, or issues like wear leveling and sector remapping may cause traces of it to remain, even after "secure deletion".


Is the mount manpage saying nosuid *is* secure, or is *not*?

As far as I understand, (I'm not using perl and even less suidperl), the manpage doesn't says nosuid is less secure, just that despite being more secure at first sight, it can be easily defeated by suidperl.


Are Push 2FA methods safe from Android and iOS Malware?

I'll be writing from the assumption that 2FA is used with two separate devices. A single device with 2FA doesn't make any sense to me considering the risks associated with malware.

Is it possible to trick 2FA?

  Now, wouldn’t a malware residing on the user’s phone simply be able to generate the “Yes” tap?

Yes, this is possible.

Pretty much nothing is safe from malware that enables root-access to a device. If you have 2FA enabled, and you have a keylogger, or some form of remote administration tool on the device, you could easily bypass almost all forms of 2FA using various different methods.

However, 2FA greatly mitigates this risk. While it is possible for malware to do this, it's also a lot less likely for an attacker to have control of every device in your possession.

  How can the 2FA app even be sure the user inputs are coming from the user and not from a malware.

In most cases, this is assumed.

Like I said, it's very unlikely for an attacker to have breached all of your devices. Furthermore, if an attacker has access to your device, "generating a tap" isn't required; they only need to phantom-click the "X", and "Y" bounds of the device screen where the image button would appear.

Here's how it would work:

Get the user's device resolution either through the system, or from a list of known devices and their resolutions.
Perform a calculation of the device resolution against the expected position of the Push 2FA button. You know it will be within a certain % of the screen. In fact, this is how video games usually position UI elements.
Malware initiates a "click" anywhere on that button's expected regions.
???
Profit.

Wait, how can you force a click? Well, a piece of malware on Android could do something like this:

dispatchTouchEvent(
   MotionEvent.obtain(downTime, eventTime, action, x, y, pressure, size,
                      metaState, xPrecision, yPrecision, deviceId, edgeFlags));

So what good is Two-Factor Authentication, then?

2FA is offering tremendous protection against someone who managed to get your password, but who doesn't have access to your computer or mobile phone.

Or maybe they have access to your computer, but not your phone. If they have access to your computer, non-Push-2FA can be bypassed quickly under the right circumstances. A keylogger, for example.

Maybe you found the malware on your device, and removed it. They might still have your password, but can't really do anything unless they also have access to your secondary authentication method.

It helps prevent unauthorized access from people who may have found, or even guessed your password. It also prevents people from hijacking your sessions.

2FA is not a one-size-fits-all solution - it's just another layer of protection. I would recommend using it.

  I keep hearing that app sandboxing, as in Android, prevents one app from interacting from another. Does this mean a malware can’t generate spurious inputs that mimic user inputs to the 2FA app

That really depends. If you have root access to a device through an exploit, you also very likely have access to whatever sandboxing is occurring as well. It's relatively easy to programmatically "click" on a phone's screen region.


There are two distinct things:

Connecting to a HTTPS Web site through a non-SSL HTTP proxy.
Connecting to a HTTP Web site through an HTTPS proxy.

The former uses the CONNECT proxy verb, and it works well. You want to latter, which is ill-supported by browsers. For instance, when you configure proxies in Firefox through this popup:

then the entry field about "SSL proxy" is about a non-SSL proxy to use to connect to HTTPS Web site, and not the other one.

It seems that Firefox cannot yet use a proxy over HTTPS. Chrome can but requires some manual trickery.

For a practical secure proxy, I suggest that you use SSH and run it as a "SOCKS proxy". This works well with existing browsers; see this answer for some practical details. The screenshot above indeed illustrates the use of such a SOCKS proxy (when a SOCKS proxy is in force, all the browser communications will go through it, for all protocols, and that's what you want).


Given that none of the common hashes has actually a mathematically proven resistance against attacks it is not a bad idea to use multiple hashes with different algorithms at the same time. This idea is not new and there are already some place where it is used. To get the best security improvement it might be useful to use algorithms which are based on very different ideas, like SHA-2 (i.e. SHA-256, SHA-384) and SHA-3.


Should I be worried of tracking domains on a banking website?

It looks like the main site is embedding script from Adobe Marketing Cloud directly into the page. While these scripts are loaded from the same server as the main site it looks like that these scripts communicate with external servers using XHR and also download new script from demdex.net and 2o7.net according to the logs of uBlock Origin.

Especially the loading and executing of new scripts from a third party outside the control of your bank is a huge security problem. Essentially these scripts can get full control over the web site, including reading what you enter, changing submitted or displayed content etc. These are essentially cross site scripting, only that they did not happen by accident but the developers of the banking site explicitly invited  these third parties to do cross site scripting.

While such use of third party services might be acceptable on a site where no sensitive information is entered, it is absolutely not acceptable whenever sensitive information is transferred or when it unexpectedly changes to the content of a web site (like showing a different account balance) and might cause unwanted actions from the visitor.


The standard in error handling to the client is to expose nothing about the inner workings and only provide what will be useful for the user to be successful.
Java error message contents do nothing to help the user. What you end up doing is exposing your code logic, which can be used against you by a malicious user.
OWASP's examples are simply to state that there is an error. And that's the standard. Any info beyond this needs to have a justification.


What makes a secure smartcard secure? Is contactless/RFID  better?

Smart card are based on standards defined for hardware and the software (operating system) residing in them. There are many standards which defines the hardware features. You can read through some smart card topics in net for hardware interface and design of an smart card.

In short I will try to give some answers below:

The contactless cards are better than the contact ones as they don't have to go through wear and tear life cycle. The life span of the card is dependent on the number of read and write cycles only.
Even if the card chip or hardware gets damaged cause of acid attacks, it can destroy the card but will never let some one to extract data like keys etc. Data loss is possible but not data theft
A smart card design standard have to implement some time based logics and some advanced techniques to ensure that the private key operations take some fixed time for operations. There are some security embedded in the crypto processor and some implemented in the OS (like unnecessary for loops) to counter the timing attacks. Modern smart cards contains logic to thwart the timing attacks wherein an external device sense the electromagnetic pulse generated around the smart card in the event of RSA operation to estimate the key involved in the operation.
RFID or other modes of contactless protocols cannot be shut for privacy reason. The implementation can have mutual authentication protocol which will let the smart card OS first validate the authenticity of the terminal before engaging on the business operations like select Key and Sign operations.

Smart card are very much secured (In fact most secured element present to my knowledge); but like any other security infra, the real security depends on how the card was initialized, the operation of issuance of card, the standard followed etc.


One good example of security theater (which has now been taken down, probably due to the ridicule) is Wells Fargo's page which does nothing but state that it is establishing a secure connection, etc.

An even better example that is rife with many instances of security theater is United's PIN and Password FAQs:

The section "Why can't I type my own security answers?" indicates that there is a pre-defined list of answers for the security questions. This results (as explained) from their narrow focus on the one threat that they think must be the most important: Keyloggers. Thus, they present a theater of restriction on security answers (that don't need the keyboard), which are insecure in the first place due to Social attacks.
The section on marketing use of security questions indicates that the answers to the security questions are encrypted. This is complete security theater since, as mentioned above, the answers are pre-defined. What could you possibly be protecting by encrypting them?

As security blogger Bruce Schneier explains, security theater, or perceived security, is not necessarily a threat to real security if it is in place on top of real security (for instance, if all data at that Wells Fargo page is actually transmitted over a secure connection) instead of replacing real security (such as if they displayed that animation on a page with HTTP components). Security Theater can even be helpful at times, such as the RFID tags Schneier mentions, which don't do a lot to stop intelligent criminals, but do set people's minds at ease about a threat that was minimal to begin with.

However, if people begin to rely too much on a façade of security (without the real security underlying it), Security Theater can be worse than useless, because users will reveal private information or perform other trusted actions that can be disastrous in the wrong hands.


If rowhammer only results in capacitor discharge, how can it flip 0 to 1?

Rowhammer only works by accelerating the discharge of capacitors.
Cells don't get charged by rowhammer, only discharged. The reason you may see a logical 0 change to a logical 1 is that modern DRAM memory uses a technique called scrambling, where a small 32-bit seed is used to power an LFSR stream cipher to encrypt memory. This encryption is not designed to be cryptographically secure. It is designed only to help reduce the electrical stress on a module if it experiences huge bursts of sequential 1s or 0s. The scrambling results in any physical bit having a roughly 50% chance of being represented as the inverse logical bit, so you see logical 0s become 1s.
It's not only memory scrambling which causes this disconnect between a physical bit and a logical bit. Some cells represent a logical 1 when they are charged, whereas others are the other way around. These are referred to as true-cells and anti-cells, respectively. The majority of DRAM is composed of true-cells. That is, capacitor discharge results in a 1 becoming a 0. It's only after memory scrambling, as described above, that this can result in seemingly random bitflips on the application level.
If rowhammer were capable of charging a discharged capacitor, we would be in a far worse situation than we are now. Because a DRAM refresh results in checking a capacitor's value and re-charging it if it was charged but leaving it alone if it is discharged, refresh-based mitigations can only protect from excessive rowhammer-induced discharge. Most extant mitigations currently rely on either increasing refresh rate (e.g. going from 64ms to 32ms intervals), or detecting excessive row activations and directly refreshing adjacent rows that may become unstable as a result (e.g. TRR and pTRR).note
The original paper gave three different mechanisms of action:

Electromagnetic coupling - Each capacitor has its own access transistor. When this transistor is triggered, it discharges the capacitor and reads out the value to the row buffer. Changing the voltage of one wordline can induce noise in nearby wordlines, temporarily activating access transistors on that line for short periods of time, facilitating leakage of their capacitors.

Bridge formation - Conductive channels can be formed between unrelated wires or capacitors. Toggling a wordline rapidly can increase the rate of leakage between bridged cells, resulting in charged capacitors discharging more quickly, potentially fast enough to corrupt them.

Hot-carrier injection - While this is not particularly relevant for short-term rowhammer attacks, it has been found that toggling a wordline for hundreds of hours can permanently damage it. This can alter the characteristics of access transistors and capacitors to increase leakiness.


A parameter is a parameter: a data element (necessarily a character string, in the context of a URL) indexed by a formal name. What is done with that parameter on the server is entirely up to the server.

We here enter the realm of suppositions. The parameter name "xmlPath" is suggestive of the parameter value being a path name for a file which uses XML. We may imagine that, upon receiving the request:

http://abc.mydomain.com/Findme.swf?xmlPath=something

then the server will try to read one of its local files named "something", decode its contents as XML, and then interpret the contents in some application-specific way. Conceivably, since the base URL includes the name "Findme.swf", the result of the server-side processing might be a SWF file to be interpreted in the client browser (specifically, in its Flash plugin). We could even infer that the exact SWF file contents will depend on the result of the processing of the above-mentioned XML file.

What can possibly go wrong ? This is the important security question, because attacks can be viewed as forcing systems to derail when faced with unexpected, abnormal or invalid input. We could try something like this:

http://abc.mydomain.com/Findme.swf?xmlPath=..%2F..%2F..%2F..%2F..%2Fetc%2Fshadow

in order to try to get the server to read the /etc/shadow file (which, on a Unix-like system, contains the hashed versions of the local users' passwords), process it, and somehow leak the file contents in what the server returns. This specific example is unlikely to work for two reasons:

On a normal Unix-like system, /etc/shadow cannot be read by non-administrative local users, and, in particular, the user who runs the Web server process. This depends on the server configuration, of course, but it usually takes some inordinately creative incompetence to make /etc/shadow readable from Web applications.
/etc/shadow is not in XML format so the decoding will fail.

Note that, for point #2, any decoding error could result in some complex debug information which may contain a dump of the input data which triggered the decoding, e.g. the complete /etc/shadow file itself... Also, we do not really know if the server really decodes the XML file. It is possible that the server simply reads and embeds the XML file "as is" in the returned SWF, to be decoded on the client. As I said, we are just layering suppositions on top of each others. Anything is possible.

A common reflex of Web programmers is to think of such vulnerabilities in terms of "sanitized input". This is wrong. It is true that any input from external entities, in particular connected Web clients, is suspect and must not be trusted; however, it does not follow at all that there would be some magic sanitation operation which would make the data "clean" and absolutely innocuous. This is the wrong mindset. There is no such thing as generically clean data. This guy:

is NOT an IT security specialist.

When input data must be processed, it must be inspected with all due care for its intended purpose. Here, the xmlPath parameter is processed as a path to a file so it must be inspected for actually designating an allowed file path, where "allowed" depends on the application. It can be surmised that the server hosts some XML files which are to be read upon normal processing, probably stored in a specific directory or directory tree. The code on the server should then make sure that the xmlPath parameter it is about to use really designates one of these files, and none other on its hard disk. This is not easy because the server code must keep track of all the possible ways of interpreting a file path by the OS; OS vendors have proven very creative in that respect. There are many encoding issues to deal with.

A more secure way of processing such input parameters is to work symbolically. The server should not expect a path but some sort of identifier that the server code will map to a local file. For instance, an xmlId parameter could be, when received by the server, hashed with some cryptographic hash function, and the hexadecimal result used as file name in a specific directory. Hexadecimal contains no dot, slash or any other special character, so there is no risk of escaping the directory and reading unwanted files.

None of the above has any relation with XSS, aka cross-site scripting. XSS is a generic name applied to attacks when some user-provided input data is reflected into some answer which is sent to another user, and the browser of that second user interprets it as a script excerpt. When XSS applies, a user can then choose some executable code (Javascript, but executable nonetheless) to run in the security context of another, target user, which opens the road to a lot of nastiness.

There is no reason to suspect that the site we are talking about is subject to XSS (at least, no more reason than "this is a Web site").


Protecting the user from unauthorized access

To be honest, there is no "right answer" and this will probably require some trial and error. I use a VPN all the time and hop IP's - but I know when I do that my bank requires 2FA every single time. That's a choice I'm willing to make, whereas your users may not. Most people with unusual IP's will accept this part of privacy, and those who use the same ISP subnet connecting from the same place (their house or place of business) will expect consistency, so a Malaysian IP will look odd and 2FA will do exactly what it's supposed to do here.

Generally, a mobile user will not have to jump through hoops unless you connect and reconnect to new networks while using your application. If using cellular data, they should be fine and maintain a consistent session.

Depending on what sector and how critical the data is you're protecting, its almost always better to lean on the side of caution. Make sure to put in a login note to tell users why and how you're protecting their data and they will either understand or whine and deal with it anyway. Breaches are in the news daily due to people trading convenience for security, and I would never want to explain to my CEO why a squeaky wheel client changed my mind about blocking an IP or using 2FA resulting in a fully compromised server and a .csv on pastebin with 1 million of our customers creds.


I raised Issue #576 on the ettercap GitHub repository for clarification. The official response is that ettercap will inject the raw contents of any file into a packet (or into its own packet, if used in conjunction with the drop() command).

It does not require any particular file format.


At what point is a cryptosystem "rolling your own"?

For typical apps, you should use a library like TLS. These do a lot more than a cipher like AES. TLS takes care of the block cipher mode, padding, integrity, key scheduling, and more. All these considerations have significant subtleties and gotchas.

Now, if you're writing something like TrueCrypt or PGP then you have very particular needs and a library will not meet these. In this case, you would need expert cryptographers on the team to have credibility - and you should still use standard algorithms, and as far as possible, standard usage patterns.


BouncyCastle and Microsoft Cng ECDH secret key mismatch

Thanks to @Dave Satchell 's comment.

I go inside to .Net Framework source code. All DeriveKey calls System.Security.Cryptography.NCryptNative.UnsafeNativeMethods.NCryptDeriveKey, which is P/Invoke of ncrypt.dll. You had to pass a key derivation function to NCryptDeriveKey

For anyone who still want to calculate it without BouncyCastle or OpenSSL: I've calculate the shared secret by translating python code.
You may need to implement your own BigInteger or using System.Numerics;
Note: System.Numerics.BigInteger is little endian, and % (mod) works different in C# and Python.


Is it viable to encrypt a 'bitlocked' drive again?

Not really unless you are attempting to prevent people that have the bitlocker decryption key from accessing the drive, presuming you can make that work at all.


Does CA/B allow a DV CA to issue IP certificate?

No, CAB Forum baseline requirements don't mention DV or OV requirements for IP addresses. However, DV certificate issuance to IP address is not allowed by validation procedures. You will have to prove that you own specified public IP address. IANA and delegated regional registrars (RIPE, ARIN, etc.) lease IP addresses only to organizations. As private person, you can lease IP address from ISP, but you can't prove to CA that you own this IP address. Therefore, private persons can't pass IP address ownership validation procedures.
Here is a link to relevant CAB Forum page: https://cabforum.org/2019/02/09/ballot-sc7-update-ip-address-validation-methods/
And some excerpts:

IP Address Contact: The person(s) or entity(ies) registered with an IP Address Registration Authority as having the right to control how one or more IP Addresses are used.
IP Address Registration Authority: The  Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).
<...>
The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the IP Address Registration Authority as representing the IP Address Contact for every IP Address being verified using the email, fax, SMS, or postal mail.

Given this, as long as you are not identified by IP address registrar, you barely can prove that you own the IP address in the request.


Propagating certificates stored in a CNG Key Store Provider

After digging a lot and making a lot of tests, I've finally found a way to "propagate" the certificate. This is what need to be done so that CryptoAPI knows that your KSP has user certificates:

Create a certificate context using CertCreateCertificateContext passing the DER encoding of desired certificate;
Create a CRYPT_KEY_PROV_INFO provInfo and set the fields:

Set pwszContainerName to a string of your choice, just to identify the key internally;
Set the field pwszProvName to the name of your provider. This is how CryptoAPI knows that the private key corresponding to this certificate is kept by your KSP;
Set dwKeySpec to AT_SIGNATURE;
The other fields can be NULL.

Associate the provInfo to the context by calling CertSetCertificateContextProperty using CERT_KEY_PROV_INFO_PROP_ID as the property ID;
Open the "MY" store by calling CertOpenSystemStore(NULL, L"MY")
Add the context to the store by calling CertAddCertificateContextToStore(hCertStore, pCertContext, CERT_STORE_ADD_REPLACE_EXISTING, NULL)

After this, the certificate will be available for use in any application compatible with the CryptoAPI, like some browsers. As an example, in Internet Explorer you can access the certificate list in: "Tools" menu > "Internet Options" submenu > "Content" tab > "Certificates" button > "Personal" tab.

Whenever the user wants to use that certificate to authenticate in a website (or other use), the CryptoAPI will call your KSP, passing a hash value to be signed be the private key.


Scan interpreted code for long lines to detect code injection?

A lot of anti-malware 'heuristic'-engines do this kind of stuff. They check entropy of chunks of code, or even the entire PE. Lots of malware is obfuscated to exist longer in the wild. The problem with this kind of detection is that is works poorly with smart-er attackers.

eg when I write exploits, I randomize everything keep things small and you will NEVER see me write persistent code to other files. Instead I'll make a reliable exploit and trigger it when I need access to the box.

Thus, yes this works for malware etc, no it won't show human attackers.
However if you can do this on running memory, that will certainly help.


How to handle root passwords for a number of embedded linux boxes?

Consider to build your application in a way that hardware access and other
high privileged actions are done by a service which is running as a privileged user (Try to avoid using root) and has a stable and well defined interface while all other logic is done without this privileges. This will reduce the attack surface and you don't need to store non-hashed passwords on the device.

Another simplified way could be to create a minimalist binary which handles the hardware interaction which you could call from your application. This binary could have the setuid permission for root set like @paj28 already suggested. However this will have some impact on the performance of the whole process since calling a external binary creates more overhead.

As @SmokeDispenser already stated it's best practice to harden the root account by disabling local and remote login and by randomly generating individual passwords for every single device. This can be done by using a setup script.


Why is DTLS-SRTP more efficient for RTP/RTCP than just DTLS 1.2?

The overhead of DTLS-SRTP is smaller than the overhead of RTP transported with DTLS. This is because the payload in DTLS-SRTP is actually SRTP and only the non-payload information (key exchange etc) are done with DTLS.

Transporting RTP inside DTLS instead adds additional timestamp and sequence numbers, which are already in RTP but which are added by DTLS too. Additionally the DTLS record layer has several more fields (content type, protocol version and length) which are actually not needed in the context of RTP/SRTP. For more information compare the definition of the RTP packet when wrapped inside the DTLS record layer vs. the definition of SRTP packet which is the payload transport in plain SRTP and also DTLS-SRTP.

In other words: DTLS-SRTP combines the efficiency of SRTP with the flexibility regarding session setup of DTLS.


How to make sandbox-only internet access?

Simple. Use a firewall in whitelist mode*.

For a similar purpose, I've used ZoneAlarm Free Firewall. Set it to whitelist mode and wait for it to ask you about giving Internet access to your sandbox application  (I've used Sandboxie). Then tell ZoneAlarm to stop notifying you about future applications and not to assume they're whitelisted.

* Whitelist mode: Unless an application is explicitly allowed to have network access, it's assumed to be blacklisted.


Sniffing WiFi using monitor mode long-term and decrypting

Did you try something like

tshark -nr input.pcap -o wlan.enable_decryption:TRUE -o "uat:80211_keys:\"wpa-pwd\",\" Passphrase:SSID\""


Auto deploy war file (backdoor/shell) to particular folder

With Linux if you had a shell you could symlink the paths together however I'm not sure if there's any method of doing this on Windows.. can you execute a file to move it for you?

Please define the restraints you are working with and what you have access to


Protecting SSH service with many inexperienced users

I suggest Fail2ban on all SSH servers, especially with inexperienced users.  This lets you block any IP that fails to log in too often (iirc, the default is 10 tries in 10 minutes gets an IP blocked for 10 minutes). This may now be possible with just OpenSSH via MaxAuthTries, MaxSessions, and MaxStartups.

In addition to that, I'd suggest regularly running John the Ripper on each user's password hash. If it finds the user's password, have it email the user a guide to better passwords and require the user to change the password. (Be sure to make that email easily verifiable; the last thing you want is for the user to discard it as a phishing attack!)

Passwords that cannot be changed are dangerous.  The password is likely hard to remember, so the user will probably write it down, and somebody else could find that note.


Is this a secure setup for a Java password manager?

First of all, you should not roll your own in situation where security is of any importance. (Just playing around for fun and learning is a different matter, of course.)

Second, I agree with schroeder that you should look at the source code of existing password managers and learn from them.

With that said, here are two big problems with your design:

Let's say that an attacker knows e.g. the victim's Facebook password. She runs that password through your function and gets 15347201. Then she substracts the value stored for Facebook in your text file (4363454) and gets the secret number 10983747. She now has the number that will let her decrypt any of the other passwords.
There is no step that is slow by design to prevent brute forcing. Usually key stretching is used for this, i.e. hashing the master password with a slow hash function (e.g. bcrypt of PBKDF2) to generate the encryption key.

There might be other flaws as well, but this should be enough to make you want to pick another scheme.


One major difference between Access Tokens and Refresh Tokens is who gets to see them.

The Access Token is handed out by the Authorization Server, and is then used by the client to gain access to the Resource Owner's resoures. The Access Token is seen by both the Authorization Server, the Client and the Resource Server.

The Refresh Token is handed out by the Authorization Server, and is only seen by the Client and the Authorization Server. The Resource Server never sees the Refresh Token.

So, the Access Token is more vulnerable; it is seen by more parties. A sloppy implementation on the Resource Server could lead to the leaking of the Access Token, while the Refresh Token would still be safe.

Credit: I had some help from this Stack Overflow answer writing this.
One scenario it mentions is that the Access Token might be sent as a query parameter, and then end up in a log file. The Access Token was protected by HTTPS during transit, but is now in the log file on the Resource Server. People who are not entitled to knowing the Access Token, might be entitled to see the log file. For example, students having a summer job as tech support.

What's important, though, isn't to try and invent a specific scenario in which things might go wrong. What's important is to realize that the Access token could leak with the Refresh Token still being safe. It's a form of defensive programming - be prepared for the case that there is a vulnerability in the Resource Server.

Since in the given situation the Authorization Server and Resource Server are a single application, most scenarios where the Access Token is compromised will also have a compromise of the Refresh Token.

As a side note, I've worked on a similar scenario. We used Identity Server as the Authorization Server. It was built into the application. If that application leaked, I would look to the Resource Server part first. Identity Server is built by security experts and, being Open Source, has been scrutinized by many. The Resource Server part of that particular application was proprietary. You may want to look at Identity Server for your application as well.


Help with viewing hidden registry entries

I recently had a problem like this only yesterday (although the adware was transmitted to mine through a web server). A useful way to get rid of it and find it in the key, that I've personally found helpful, is to download an adware cleaner (like adWcleaner), as they show you where the viruses are being generated from, and also give you the option to remove them.

On a side note: if you want to find the IP of the server transmitting the virus (if the virus transmits data through a webserver), download Norton, as it will say An intrusion attempt by "website" was blocked, along with the IP which you can then Nmap, for the TCP server.


Does a two-factor authentication dongle (OTP) which is always inserted in MacBook add a security benefit?

Yes, it adds a security benefit for remote attacks. Just assume you type your password into a chat window instead of in the password box on a website. Using 2FA, nobody in the chat can login into your account, even when your YubiKey is connected to your Macbook.

You may be a bit more at risk when the Yubikey types your TOPT into the same chat, but with a little bit of luck it will expire before someone realizes what it is and where to login with it. And leaking one TOTP does not leak the master key needed to generate the next one.


In what kind of software/webapplication/OS can I found them ?

Literally anything.

  How can I recognize one ?

By reverse engineering the software and carefully analysing it for flaws in authentication and access control, as well as issues with memory access in native applications. It's the same process by which you'd find any other vulnerability. This is not a trivial task, and entire books have been written on the subject.

If you're looking to know the difference between a generic security vulnerability and a backdoor, the difference is the intent of the programmer who put it there. You have to find evidence and use intuition to identify if it was purposeful or not. Usually this is not a yes/no answer.

  How do I prevent them ?

You basically can't. You just have to expect software to be broken and have a plan to (a) keep things up to date, and (b) deal with it should there be a breach. It's not about if, it's about when.

  Is the analogy good to compare them to have root access (in a Linux way) ?

Not exactly. A backdoor is anything that provides a lesser-authorised user to gain access to something they shouldn't. The backdoor might allow full access to an unauthenticated user, or it might allow some limited access to an unauthenticated user, or it might allow an authenticated low-privilege user to gain access to something at a higher privilege level.

  Any more relevent informations about them.

There isn't much, really. Backdoors are just intentional faults put into code to give someone access outside of the normal security model.


Setting expectations of a vulnerability assessment?

From the InfoSec perspective it's perfectly reasonable. No surgeon can (or should!) guarantee a 100% safe operation, no lawyer can guarantee conviction or acquittal.

Of course, the customer doesn't want the InfoSec professional to take their money and hide behind that clause in their contract either, if something were to slip past the audit.

I'd suggest that the solution to the issue is exactly what you mentioned - setting the right expectation. The customer should expect that the InfoSec team will do their very very best to detect common, easily exploited vulnerabilities. There are many ways to signal that you truly intend to do your best.

Financial guarantees specific to the scope of the audit request: e.g. 100% refund for a SQL injection exploited post-audit.
Reputational guarantees: e.g. "Secured by ACME InfoSec" text on their website, so that the InfoSec professional has a vested interest in keeping the site secure.
Multiple-audit guarantees: e.g. Offer to have a competing InfoSec firm provide a second opinion for comparison.
Testimony: From other customers whom you have helped in the past.
Proof of Work: Demonstrate actual effectiveness of your recommendations. e.g. Have independent pen-testers attack before and after your recommendations are implemented.

Of course, this all depends on a customer that understands that the only certainties in life are death and taxes.

For those that insist on 100% guarantees, you could certainly provide those within scope (point #1 above). You could (and should) include a maximum liability clause - e.g. the most that you will have to pay is $x.


How can I export my private key from a Java Keytool keystore?

Use Java keytool to convert from JKS to P12...

Export from keytool's proprietary format (called "JKS") to standardized format PKCS #12:

keytool -importkeystore \
    -srckeystore keystore.jks \
    -destkeystore keystore.p12 \
    -deststoretype PKCS12 \
    -srcalias <jkskeyalias> \
    -deststorepass <password> \
    -destkeypass <password>

...then use openssl to export from P12 to PEM

Export certificate using openssl:

openssl pkcs12 -in keystore.p12  -nokeys -out cert.pem

Export unencrypted private key:

openssl pkcs12 -in keystore.p12  -nodes -nocerts -out key.pem


Cracking MD5 passwords with the same salt

Computation is simple enough, though there are some hidden assumptions.

On this site, one can find benchmarks for some GPU-based cracking systems. One of them, featuring no less then eight AMD R9 290X GPU, can compute 93.8 billions of MD5 per second.

There are 2610 = 141167095653376 possible sequences of 10 letters. At 93.8 billions per second, they can all be hashed in about 1500 seconds, i.e. 25 minutes. On average, finding the right password will take half that time (sometimes you get lucky, sometimes you don't).

However, mind the details:

MD5 is a hash function. Its standard definition does not speak of passwords or salts. When you have "passwords hashed with MD5 and a salt", then you really are using some unspecified algorithm which uses MD5 as one of its internal elements. Whether the computational cost of the algorithm can be reduced to "just one MD5" depends on that algorithm. Some MD5-based password hashing functions actually imply several MD5 invocations, possibly a lot (in that sense, PBKDF2 with HMAC/MD5 is an algorithm "based on MD5" and can involve billions of invocations for each password).
The computation above assumes 10 lowercase letters. If the password may include both lowercase and uppercase letters, and they are treated differently, then the number of combinations rises to 5210 = 144555105949057024, for a corresponding brute force time of 17.8 days. If we use printable characters (the 95 ASCII signs, excluding control characters but including space), the number of combinations rises again, up to 9510 = 59873693923837890625, for a brute force time of about 20 years (again, this is for the complete space exploration; attack time will be half that value on average).
Conversely, when normal human users are supposed to generate a password, they come up with "witty" passwords, not "random" passwords. Among 10-letter possible passwords, some are widely more probable than others. Attackers will try the passwords by beginning with the more probable ones, and this reduces attack time quite a lot.
The system used here as example is quite big in amateur terms (8 big GPU...), but an industrious attacker may accumulate more power. He may also rent it (from commercial cloud systems), which can be cost effective. There is no absolute answer to your question if you do not first define the attacker's budget.


How to update large encrypted files on a server

Most encryption algorithms do not propagate changes to subsequent blocks, so you can edit the file in place with the key, and the amount of ciphertext you will be a multiple of a certain size (usually the size of the cipher block or a multiple thereof). The way large encrypted files are typically updated is by having the encryption done transparently, as is the case with filesystem and disk-level encryption.
The only kind of encryption which would force you to re-encrypt everything and re-upload it would be one which uses an all-or-nothing transform, which no modern file encryption methods use.


openssl enc uses md5 to hash the password and the salt

The OpenSSL apps need to be used carefully, they often have old and possibly insecure defaults, at least by contemporary standards.

In this case openssl enc defaults to using a digest of MD5 (apps/enc.c)

    if (md && (dgst=EVP_get_digestbyname(md)) == NULL)
            {
            BIO_printf(bio_err,"%s is an unsupported message digest type\n",md);
            goto end;
            }

    if (dgst == NULL)
            {
            dgst = EVP_md5();
            }

The -md "message digest" option can be used to set this explicitly, you can use any supported digest such as sha256:

openssl enc -md sha256 -e -aes256 -in infile.txt -out outfile.enc -pass pass:foo

Some of your assertions are correct, but they do not quite apply here, specifically since an attacker does not know the digest output a collision attack does not apply.

Finding a collision is only useful sometimes, e.g. when MD5 output is used as a signature or integrity check. A collision attack requires that you have a hash output to work with.

In this case MD5 is being used as a key-derivation function. For that, what is usually more interesting is pre-image resistance: given a digest you could work out an input (e.g. password) that would generate it. MD5 has good but imperfect pre-image resistance, ~123 bits instead of the intended 128, see RFC6151.

Given only an encrypted file, if the attacker's task is to recover the encrypted data, then he must discover the symmetric key (key+IV) used to encrypt. This key is also a digest he can compute from a pass-phrase which he can discover instead (a salt, if used, is available in the file).

The attacker does not know the password or the key (digest of salt/password), either one will do: which is cheaper to find? What might help an attacker is if the MD5 output is biased, but it's not, as far as I know.

(Strictly there may be two scenarios: recover the password in order to prove something, not necessarily access to the encrypted data; or only recover the key in order to access the encrypted data.)

The two obvious attacks are:

brute force the entire (symmetric cipher) key space, if the KDF (hash/digest) output is biased then this will be smaller than it should be, which may help the attacker
brute-force the password space, if the input was chosen by a human then this will be smaller than the key space (the salt will eliminate pre-computed attacks though, enc uses a random salt by default)

Ideally, we want a good KDF with no bias, an output at least as large as the expected input entropy, matched to the symmetric cipher keysize, and expensive so that attack #2 doesn't offer a short-cut.

Using a digest like MD5 with a short output (128-bit output) as a KDF means that the key used to perform the encryption is only 128 bits, and in this case not as long as your required pass-phrase (~160 bits, 62^26). Also consider the symmetric cipher key size that will be used, ideally these should be matched.

The biggest problem here is not the potentially problematic use of MD5, it's that the KDF that openssl enc uses is "cheap", specifically it only uses one round, making brute force attacks on passwords the best attack (apps/enc.c, line #569):

             EVP_BytesToKey(cipher,dgst,sptr,
                            (unsigned char *)str,
                            strlen(str),1,key,iv);

The sixth parameter to EVP_BytesToKey (hard-coded to 1) is the count, designed to slow down an attacker (or not, in this case). What should be used instead is a robust, expensive key-stretching function like bcrypt or scrypt.


Fixing an OpenSSL vulnerability at the firewall

Is OpenSSL Padding Oracle vulnerability something that can be fixed at
  the firewall level? I suspect the firewall at the server that received
  the 'A-' was successful in filtering out the packet that was trying to
  test this vulnerability. Am I right? Is this something that can be
  fixed at the firewall level?

No.  SSL/TLS protocols have anti-tampering protections; if, for example, the firewall were to alter any of the handshake, the handshake would fail because both sides validate that what they sent was what got seen by the other side.

Other configurations might protect you.  If you had a SSL offloader or man-in-the-middle proxy, something which terminated and then re-opened connections so that you have connections #1 and #2:

[Server]<---1--->[Proxy]<---2--->[Scanner]

Then that would do it, because the vulnerable SSL library on Server isn't being touched by the scanner.

  However, the version of OpenSSL we have on both the servers are old
  and identical:

[user@alpha01 ~]$ rpm -qa | grep openssl
openssl-1.0.1e-30.el6_6.4.x86_64

And old.  That version is superseded by openssl-1.0.1e-48.el6_8.4.x86_64.rpm.  I would recommend updating it in both places and seeing if that makes it go away.  Restart your services after updating, of course.

Notice that I haven't really addressed the root question of "Why do two servers with the same libraries give different results."  That's because there's not really enough information to tell.  Are the server daemons the same on both hosts?  Could one be using different SSL libraries?  Did the scanner exercise the same level of testing against both?  How many times have you scanned each host?  Are the results solidly consistent?

With all that unknown, and given that you're running a known deprecated version of OpenSSL, my recommendation is to patch and test again.


Why is JavaScript disabled in the Tor Browser Bundle?

Short answer: JavaScript isn't a threat per se, but it can become one. So disable it in critical situations just in case.

JavaScript is globally enabled in Tor Browser Bundle by default. JavaScript, per se,  won't reveal your IP address, it's just that many times there are security problems with the JavaScript components in your browser that would allow evil people to execute malicious code on your computer. That malicious code can reveal your IP address, MAC address, and a lot more information.

You use Tor to protect your privacy, so you'd want minimize the risk as much as possible. That's why you disable JavaScript, Flash, Java, and other components. You don't disable them because they'll compromise you all the time, you disable them just in case, which is a good practice in situations where you want to be careful about your privacy and identity.

As for your other question, Tor creates a local SOCKS proxy and other applications needs to connect to that proxy. So far, Tor doesn't have a user-friendly way to route all system traffic through it, but there are some ways to do it. I highly recommend using Tails, you can easily install it on your USB stick and it will load a full operating system configured for your privacy, with everything routed through Tor.


If I typed username and password, but wrongly clicked another button to go to another page instead of the login button, is there any security risk?

I admit this question seemed like it had a straightforward answer at first but then after looking into Facebook's page and the button functionality it definitely does beg the question.

I discovered that if you have the username/password fields filled in with the credentials of a legitimate account, or have auto-fill username/password in place pulling from either Chrome itself or a password manager- which may/may not be a good practice depending on your level of security paranoia- then selecting the 'Create New Account' button actually does send a POST message that includes details of your login information from the previous page, including username/password. If you're curious and aren't already aware, this can be done by simply monitoring the network requests in your browser.

Despite this, I would still say that it depends on the application you are interacting with. In this case, since it's Facebook and- though this may be a point of contention within the community- we can trust Facebook with our data, then as long as the POST request that had my username/password information in its payload was made over secure transmission I can presume to be unworried about a security risk. I would only imagine that at this point the information being sent to Facebook via this POST request would need to be equally as secure as the login button itself.

I have never encountered another site that does this, but am hoping to see other answers on this based on other experiences.