(Quick answer, I don't have the time to research all I remember and double-check my facts.)

There are multiple things to consider here:

USB sticks may carry payload that you do not know is there, e.g. a virus to infect the computer it's plugged in to.
Things like BIOSes, network cards, etc. can often be flashed to upgrade the firmware. You could also install viruses on here and they often have full memory access.
USB sticks are rewritable. There are very few that actually implement hardware write locks, e.g. by using a physical switch. I think Jacob Appelbaum (from The Tor Project) looked into this, he mentioned it somewhere... I forgot where. Such USB-sticks are basically unobtainium as far as I know.
RAM memory is not off and gone: it fades. Off the top of my head, it's gone after about a minute in room temperature. You can google this, search for cold boot attacks.
Be sure to power off the computer (if you aren't sure, pull out the cable and battery), in standby mode memory is obviously retained.
The data is only as secure as the host. If your offline computer contains a hardware keylogger that someone then later retrieves when you are out of the house, well, being offline didn't help much in this case.
I think it was with a microphone inside the same computer, but some chips on the motherboard may leak data. There was some sort of side channel attack to extract private keys... I don't really remember, but you might want to keep a bit of distance between the computer and other systems. This Google search seems to give some info.

So it depends what you want to protect against. Are you hiding state-secret information, or are it love letters that you are trying to keep private?

In theory you're right: under normal circumstances all data will be gone when the live USB-stick is removed and the computer is powered off. In practice, there are a lot of things that (powerful) adversaries can do to all parts of the system.

If you buy a USB-stick, assuming it's not backdoored to start with (which is a reasonable assumption under normal circumstances) and you only use it on your offline computer, then I don't see how it could get infected without someone physically touching it. Same goes for the computer. The problem is: how do you get your OS while offline? Somewhere you somehow need to connect to the internet to create the live boot. Perhaps this would be safest on a computer of a friend that is not tech-savvy and has no clue what you are talking about, and who is preferably not a close friend either. For bonus points, pick another friend and use his computer to verify the checksum. I think as individual, this is about as close as you can get to protect against extremely powerful adversaries.

By the way, lots of stuff in this post may be tinfoil hattery, but I'm trying to talk in terms of "what would be provably secure." For example one would normally assume that "of course a computer that you just bought is not backdoored", and it would be tinfoil hattery to assume otherwise, but how do you know? If you are not trying to protect against powerful adversaries like a government though, much of the advice in this post can be disregarded.

Edit: This answer is only about the first paragraph of the question, not the second that the asker added in an edit.


Problems during Pen-testing of SCADA systems

The single most important rule when testing production SCADA systems is never test production SCADA systems if there is a risk of taking down any critical service, or spilling an oil pipeline etc. Always use a test environment.

If however you have to test in live, the best rule to adhere to is to ask for confirmation of every step - written confirmation, from the system engineer. This does make a proper test very cumbersome and expensive,but dramatically reduces the risk of you doing something fatal.

And if it is expensive enough, perhaps for next year's test you might get a test environment...


How would you characterize a cyber surface?

I believe the OP is referring to a concept I usually call "Attack Surface"

Attack surface is mental visualization tool used to picture the aggregation of all the various vectors an adversary might use or attempt to use to affect the confidentiality, availability or integrity of your data or systems.

To envision an attack surface one should visualize the system in question and the adversary.  An example of why both should be pictured: Imagine a remote adversary attacking a windows machine. He may be able to steal information from a device's memory by physically removing the drive and mounting it on system under his control, but we can exclude this vector from the attack surface because it is impossible without physical access.

If you think through each vector and imagine each of them taking up a physical amount of space you can envision it being harder to defend the larger that surface is.  For example image a soccer(football) goal that is twice as large as regulation size...it would be much easier to score against.  In this analogy you could think of preventative security controls as defenders that stand at the goal line as during certain penalty kick situations.  They are somewhat static but can significantly reduce the attack surface if positioned correctly. An example of a preventative control would be a firewall.

To imagine security monitoring controls imaging standing in a soccer(football) stadium and being unable to see the goal area because of a massive person standing in front of you.  If you had a camera that could see some portion of the goal you could monitor if a ball passed through that portion (and only that portion)..this would be a monitoring control such as an IDS.


There are a few things that need to be done in order for you to serve your private networked sites over HTTPS.

You need to setup an OpenSSL based certificate authority.  I don't have a link handy, but you can google it and I am sure you will find what you are looking for.
You need to generate a CSR - certificate signing request which basically provides the details around the site that you are trying to protect with HTTPS, eg the common name, which is the actual URL.
You need to generate a certificate singed by the certificate authority that you created in step# 1.
You will then adjust your web sever or application server to use the SSL certificate and the certificate authority certificate that you created. You should be able to figure the steps for this via a Google query.
Once the certificate is setup on the server, you need to install the certificate authority certificate in your browser. There are a bunch of steps for each of the browsers, Google can help with locating the exact steps.

Once the certificate authority certificate is installed on your client machine's browser, when you visit the URL of your site, using the common name that you provided while setting up the certificate, you should not see a warning, but a green HTTPS padlock in the browser address bar, confirming that the certificate is trustworthy.


A tool like HP ArcSight can be customized very deeply, and just writing the right use cases and rules to correlate relevant events and alert on meaningful incidents, is super hard. Many organizations fail miserably implementing ArcSight.

Just getting raw logs through connectors to logger and then to ESM, and then writing use cases is a project that depending on the size and bandwidth of your network can cost from $100K to $3M.

But once it is up and running, now part of the SOC daily routine is to look into the alerts and tune the tool to avoid too many false positives; it involves revising the rules and use cases. For the first six months, if you do not have the right resources, you may only see red dashboard full of alerts that you don't know which one to pay attention to.

When an incident happens, a world-class SOC has a well defined triage, investigation, and escalation process to handle it, with at least 2 tiers of analysts. A 24x7 SOC should respond in near real time, and take appropriate actions against the attacks that was detected.

Usually, these tiers are security experts, which are expensive, and rotating in shifts make it even more expensive. The service must be reliable, which requires lots of redundancy. They also should do the threat intelligence gathering and research on the new trends in cyber attacks for you. These are expertise that are rare and expensive.

But just $1M per year for SOC is not reasonable. If you go to big players, because they use the economy of scale, they may offer a better deal.


Should every website or web-application have a Responsible Disclosure Policy and what are the drawbacks of having such a policy?

Would this attract hackers? Yes, of course, that's the point of it. Good hackers, bad hackers, grey / white / black / multicolor hat hackers. They will come and inspect your server's front-door.

Should you be afraid of it? Normally, your security posture should not rely on the absence of any attacker, otherwise you indeed have a big problem to solve. When you put such policy in place, it means that:

You are sufficiently confident in your server security, you have setup the proper mitigation and monitoring systems,
You have people in measure to directly handle potential security incidents,
You have the right to take such initiative (you are not renting your server to an external service provider who could take the initiative of suing the discloser),
You have established the proper communication around this (a lot of companies rightfully fear about loosing competitiveness when uninformed customers and partners may have to choose between a company publishing information regarding its security issues and a company showing no security issues).

As I understand it, while you engage yourself to not sue people testing your security in the perimeter defined by your policy, you do not have any commitment to open all the doors to make their investigations easier (as it may be done upon contractual assessment to speed up the process and ensure a deeper coverage of the targeted application, for instance by disabling a web application firewall to focus the tests on the application itself).

All you defenses remain nearly the same, all threshold are still active. If a tester is blocked for a few minutes, if he gets Captcha to solve, etc.: all this is to be expected and is part of the game.

The only difference is that, instead of working only from time to time, your first-level defense mechanisms will be triggered on a far more regular basis, with certainly some people trying to maliciously abuse them, but also benevolent hackers analyzing them and ready to contact you in case of any flaw has been found.

So to summarize:

Without any responsible disclosure policy:

Malicious bots and attackers try from time to time to hack your server,
Your defense systems are triggered occasionally.

With a responsible disclosure policy:

There might be an higher amount of malicious attackers trying to hack the server, but this is not even sure since it is usually the sign of a sane security posture (the fact that you advertise that there actually is a security team may put your server out of the low hanging fruits),
Your first-level defense systems will be triggered on a regular basis,
In case of failure of these defenses, there is a high probability that you will be contacted by a benevolent hacker informing you about the issue.

So, all-in-all, I have the impression that the latter gives a better security feeling that the former.


Significance of the difference between DSA and RSA in signature verifying speed

No, you're not missing anything. Current processors for desktops and laptops are just ridiculously fast. OpenSSL is a native application that can make most of that.

In general CPU speed on laptops is not much of an issue. It can be an issue on embedded devices of course. Or on higher level languages. Or when latency is very important (e.g. authentication of many TLS connections). Note that normally you don't need to verify one challenge-response, you need to verify a chain of certificates as well. So there are many reasons why verification speed suddenly becomes important again.

In general it is much better to focus on security first and to perform optimizations later. Having a good, flexible design should allow for any signature generation algorithm. If somebody tells you not to use DSA because of speed issues for 2048 bit keys without knowledge of the runtime system then I would seriously question their experience level.

Kind of like the manager that tells you not to use new in methods of your Java toString implementation because it could slow down the application.

Note that 2048 bit keys are starting to get bit too small for comfort for applications that require high security. If you use, say, 3Ki keys then the performance will drop (although the algorithms that uses RSA signature generation will suffer the most).

There may be other reasons to choose RSA over DSA of course. With RSA you also don't need to know about these pesky domain parameters and subkey sizes. RSA is pretty easy to understand and use compared to DSA and ECDSA. So in that sense you could ask yourself why you should not be using RSA.


How can Huawei (or any other telecom vendor) provide verifiable security assurance?

Providing fully verifiable security assurance is impossible with today's complex systems. Even if the full source code is offered for audit (which Huawei seems to offer) this might catch the obvious backdoors but it will not catch bugs that can lurk deep inside and which might also be used to provide backdoors into the system. And it will also not catch explicit or implicit (i.e. bugs) which were added in patches unless these patches are again audited - which is costly and time consuming. And this only covers software - there is also the hardware and firmware which is complex too and might also have explicit or implicit backdoors.

Still, providing the software and design documents for audit might actually add enough trust that the system does not have explicit backdoors. When doing common criteria evaluations it is common that the auditor has access to software and design documents - at least for the higher levels of certification like EAL4. Thus, while not being fully verifiable secure or formally verified it might be considered sufficiently secure for the purpose and the vendor might be considered trustable.

But of course, this means that not only the vendor has to offer all this access (many do) but that there is actually an interest in even considering the vendor as trustable. There are several factors which can play against this: political and economic factors but also the goal to reduce potential risks. The first ones should be clear, i.e. one can use trade restrictions as a political weapon and one can also want to favor local vendors against foreign vendors for economic reasons.

But reducing the risk is also relevant: one does not want to have a vendor with potential ties to or dependency on a political, economic and military foo to have control over sensitive or critical infrastructure. The vendor might be considered trustable now. But this might change if conflicts increase and in this case the foo has an advantage if it could control an essential part of your infrastructure - like the mobile network, communication equipment, electric power stations etc. This is especially true with vendors which are located in countries where it is likely that the government will lure or pressure the vendor to play in the states interest, i.e. China, Russia but also (as also the Snowden affair has shown) the USA and Israel (which has known tight connections between cyber-security companies and the military).


I need to compute a string whose SHA256 hash matches a given prefix. How should I approach it?

If I have understood your problem correctly (from the clarification in your comment), in short, brute force will be your only option. But if you know a few boundaries to the problem and you don't mind storing some (potentially very large) amount data you can try to make shortcuts for yourself for the future.

If, for example, you know that you will only ever need to match a maximum prefix length of, say, 32 bits, then each time you calculate a hash that doesn't match your target, save the string and the 32 bit prefix into a table (discarding duplicates, of course). Then, with each future search, you can search for the required prefix in your table to see if you've precalculated it, before resuming your brute force search from where you left off.

Sadly, there's no way to use your precalculated prefixes to exclude candidate strings (such a thing would count as an extraordinarily strong defeat of SHA-256) and shorten your search. My advice would simply be to brute force your way through every 256-bit starting string beginning from all zeros.


Is EV green extended validation slower than a regular SSL?

A EV certificates is just a normal certificate but with a few special issuer specific X509 extensions. The browser compares these extensions against the extensions expected for EV certificates on the issuers CA and if they match it will show the green EV bar.

These special X509 extension are not related to the strength of the certificate and in fact the strength used is the same as with any other modern certificates, i.e. usually 2048 bit with SHA-256 as signature algorithm. This means the time needed for validation of the certificate is usually the same as with other certificates. The only major difference is that browsers usually require a successful revocation check with OCSP when connecting to a site with an EV certificate. And if no OCSP stapling is used this revocation check will result in an additional TCP connection to the OCSP responser which will slow down the initial connection setup.

  ... my provider only allow the EV green certificates to be on the root (no sub domains or wildcard *. allowed). Is that normal?

The rules for EV certificates are defined by the CA/Browser forum. Thus you will find in section 9.2.3 that wildcards are not allowed:

  Wildcard certificates are not allowed for EV Certificates.

I don't see any special rules for sub domains though.

  Can I mix EV green for the root and regular SSL for all sub domains *.mydomain.com ?

You could do this in theory. But it would be better to simply include all the hostnames you use into the EV certificate as subject alternative names.


Is there an easy way to secure Apache on debian?

I know your pain; unfortunately, there really is not much you can do if you're using the core rule set.

You will need to whitelist rules using SecRuleRemoveById. This can obviously get cumbersome. So, what we do in our infrastructure is note what rules are whitelisted for what CMS and whitelist all those rules based on the CMS' that are being ran on the server.

I've been told that TrustWave has specific rules that apply to specific CMS'.


Why should we protect access to password hashes?

Safe password storage algorithms have two main features: they're one-way, and they're slow.

Being one-way means that given the output, you cannot efficiently compute the input. Efficient means: anything faster than trying all inputs until you get a matching output.
Being slow means that computing an output (the stored value) from the input, takes a while. Because they're one-way, you need to try inputs, and if trying an input takes ten billion calculations on your CPU, then it's going to take a while before you checked all possible passwords.

But what if your password is in the top 10 of worst passwords, like "admin" or "123456"? Then an attacker is going to guess that within a few attempts, no matter how strong your hashing algorithm is.

Therefore, people with weak passwords will always be at risk if their hash is known to an attacker. That's why we keep them secret.

When we log in to a system, we don't want to wait 5 minutes for the server to complete the password algorithm, so those algorithms are still quite fast (something like 0.1 seconds). Because computers get faster over time, we also need to increase the number of computations done, so that it still takes an attacker (with modern hardware) a long time. Or maybe we want to upgrade to a different algorithm that protects against a certain kind of ASIC or GPU cracking program. In those cases, if the old hash is known to an attacker, they can crack the user's password more easily. So additionally, keeping the hashes secret as long as possible, we also have the most up-to-date protection at the moment the hashes get hacked.

Some people include pepper in their password hashes (see this question or Wikipedia), in which case it would be perfectly safe to publish the password hashes so long as the pepper value remains a secret. But then the question is: why would you? There is usually no advantage to publishing the hashes. When the pepper value leaks, attackers can start cracking the oldest hashes you ever published. If you protect the hashes instead of posting them publicly, attackers first have to obtain both the pepper and the user database before they can start cracking anything.

Omitting this precaution (of protecting password hashes) should never be done without the user being warned of the risk. One example of this is a tripcode, where the hash gets published as proof of identity without needing a database. This is the only case that I can think of where publishing hashes of memorized secrets is a good idea. Other hashes, such as signatures of software, are of course a different topic because those do not function as passwords.


Why is Bruce Schneier recommending symmetric crypto over public key crypto

This preference of symmetric cryptography over asymmetric cryptography is based on the idea that asymmetric cryptography uses parametrized mathematical objects and there is a suspicion that such parameters could be specially chosen to make the system weak. For instance, when using Diffie-Hellman, DSA or ElGamal, you have to work modulo a big prime p. A randomly chosen prime p will be fine, but it is possible to select a special p which will "look fine" but will allow easy (or easier) breakage of the algorithms for whoever knows how that special p value was generated. Such primes p which make crypto weak are very rare so you won't hit one out of bad luck (as I say, a randomly chosen prime will be fine).

This means that good cryptographic parameters are nothing up my sleeve numbers. If you look at FIPS 186-4 (the standard for DSA), you will see a description of a generation system for DSA parameters (namely, the big modulus p, and the generator g and group order q) which is demonstrably non-malicious. This works simply by showing the deterministic PRNG which presided to the generation of these values; by revealing the seed, you can show that you produced the parameters faithfully, and thus did not indulge in "special prime crafting".

A jib can be made against the standard NIST elliptic curves (see FIPS 186-4 again) because these curves again have some parameters, and NIST forgot to use a deterministic PRNG as described above (actually, NIST is not at fault here; these curves were inherited from SEC, so the mistake was probably Certicom's). The Brainpool curves attempt to fix that mistake. (Note that among the 15 NIST curves, at least the 5 "Koblitz curves" cannot have been deliberately weakened since there is no random parameter in them at all.)

Ole' Bruce turns all of the above into a generic anathema against asymmetric cryptography because he wanted a punchy line, not a more correct but lengthy explanation on group parameter validation, as described above. The lesson to remember is that the complete design of any cryptographic system shall be as transparent as possible, and this includes the generation of "seemingly random" parameters.


"Who the entity knows." I've Googled for weeks and can't find results

A Google search for authentication "who the entity knows" returns a few hits.  Here's one PDF:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.2471&rep=rep1&type=pdf

  Fourth-Factor Authentication: Somebody You Know

  ABSTRACT
  User authentication in computing systems traditionally depends on three factors: something you have (e.g., a hard-ware token), something you are (e.g., a fingerprint), and something you know (e.g., a password). In this paper, we explore a fourth factor, the social network of the user, that is, somebody you know.

  Human authentication through mutual acquaintance is an age-old practice. In the arena of computer security, it plays roles in privilege delegation, peer-level certification, help-desk assistance, and reputation networks. As a direct means of logical authentication, though, the reliance of human being on another has little supporting scientific literature or practice.

  In this paper, we explore the notion of vouching, that is, peer-level, human-intermediated authentication for access control. We explore its use in emergency authentication, when primary authenticators like passwords or hardware tokens become unavailable. We describe a practical, prototype vouching system based on SecurID, a popular hardware authentication token. We address traditional, cryptographic security requirements, but also consider questions of social engineering and user behavior.


Infection is not the likely intrusion vector: it was likely that the account was compromised.

The user's passwords should be changed right away and the account inspected to see if other accounts have been linked, etc.


How safe is the ownCloud encryption in a trusted LAN?

Pascal's blog entry shows a few weaknesses, some of which being recalled in ownCloud's advisory, but they did not recall the worst.

The storage of encryption keys as files in /tmp is already pretty bad, especially since /tmp is a true disk-based directory in many Linux and *BSD operating system (I usually configure my /tmp to be a memory-based filesystem, but this is not the default). Therefore, some encryption keys will make it to physical storage. And it is well-known that deleting a file does not wipe the data out; it merely marks the corresponding blocks as reusable. Data is not written over until some new files are created. Thus, it can be assumed that some keys will leak if the unpowered server is stolen.

The worst weakness is about key generation. Pascal states it as:

  The computation of the overall entropy, and thus the effort to guess a key, is left to the reader… Not to mention the maximal achievable amount of  4*log2(99999-10000+1) = 65.8 bits of entropy, which are far from the recommended minimal value of 80 bits.

The bit about "65.8 bits" is misleading: it means that the way ownCloud generates keys implies a maximum entropy of that amount... assuming that the involved PRNG are perfect. But they're not. The 65.8 comes from the key production as four integers in the 10000..99999 range. But they come from a Mersenne twister PRNG, itself seeded with another PRNG, which is in turn seeded from the current time and the thread identifier. The time is taken to the microsecond; let's assume that the attacker knows that time with one-second accuracy. Let's also assume a 16-bit thread identifier. That's, at best, 36 bits of entropy. A mere PC will wade through that in a matter of, at worst, a few hours (encryption uses Blowfish, which has a rather expensive key schedule, but not that expensive).

Of course, since there is a password involved, attacking the password is probably even easier, but this low-entropy key generation prevents strengthening from a big, random password. This is rather hopeless. If the Mersenne twister was replaced with a decent, cryptographically strong PRNG with appropriate seeding (e.g. simply reading from /dev/urandom), then the other weaknesses would be sources of serious concern, but the weak seeding trumps everything.


Decide for client certificate auth in https based on hostname or url

A) Decide on doing client certificate authentication based on the hostname

This can be done even if both domains are served on the same IP address as long as the browser sends the target hostname within the SNI TLS extension. All modern browsers do this by default and most but not all apps on recent mobile systems.

  B) Decide on doing client certificate authentication based on url

It is not immediately possible since the URL is unknown on initial TLS handshake. It can be done with renegotiation inside an existing TLS handshake.


I installed a windows app that stores cookies in a plain text un-encrypted database. Is this a problem?

EDIT: Based on your comment, it sounds like your concern might be less "why are these secrets not encrypted?" and more "why is this app storing full Google session tokens instead of using OAuth to get restricted-access tokens?" That is a perfectly valid criticism of the software; it is highly unlikely that it needs more access than it could get through OAuth, and using OAuth is more secure because in the event that the token (or the app itself) gets compromised, it can do less harm to your account and it is easier to tell what happened and close off access.

Just don't expect the access token or refresh token to be stored encrypted, unless the app asks you for a password every time you launch it (and even then, it's possible for a malicious program to steal the tokens anyhow). There are some apps for which the extra security gained from demanding a password on every launch is worth the hassle (password manager apps/extensions like LastPass or encryption tools like gpg often do this, for example). Unless that's happening, anything else that is done to the secrets is basically obfuscation, not security.

The standard security model for Windows (and other modern general-purpose operating systems) assumes that any code you run is trusted to have whatever privileges you run it with. In other words, if you don't trust a program with access to your saved cookies (and all major browsers store cookies either in plain text or easily decryptable by a running program), then either run it in a sandbox that has limited access to the file system (such as a Windows Store app on Win8+, or the highly-restrictive sandbox Chrome uses for its renderer processes), run it under a different user (standard users cannot read the contents of another user's profile directory, including the AppData directory), or don't run it at all. "Full-trust" (non-sandboxed) apps running under the same user account do not, and cannot, keep secrets from one another; the burden is on the user to not run such full-trust software unless you do, in fact, trust it.

While it might give you some peace of mind if the cookies were encrypted, what encryption key would you use, and where would it be stored? You'd either need to enter a password to generate a key every time you launch the app, or the key would need to be stored in such a way that any other programs running under your account could also access the key and then access the files (there is no such thing as data that only one program could ever read). For that matter, if you run a malicious program under your account, it could simply attach to the Electron app as a debugger and read its secrets straight out of memory.

If you're concerned that somebody running software outside of your account - for example, a privileged process that can read into other users' home directories, or another operating system entirely (such as a thief might use to bypass Windows' protections and try to steal data from your hard disk), you could use encryption to defeat that. Windows offers three main ways to do this: DPAPI (Data Protection API), EFS (Encrypting File System) and BitLocker Full Volume Encryption. DPAPI encrypts or decrypts arbitrary blobs of data with a key that is protected by the user's password; a program must specifically request the data be encrypted or decrypted but doesn't have to supply a key because if the program is running under a logged-in Windows session, the user's key is used (if the program is not running under the user that encrypted the data, this won't work). EFS encrypts specific files (setting it for a directory encrypts all the files within that directory) also using a key protected by your Windows password, but transparently decrypts the data on read (and re-encrypts on write) for processes running under your account. So long as an attacker cannot guess / brute-force your password the data is safe, but malicious software that you run (or that an attacker runs after compromising a program you ran) can still read the data. BitLocker encrypts the entire hard disk (aside from a small bit containing some boot code to enable decrypting the rest) and can be set up to require a password when the computer boots to Windows, but once Windows is running, any software (not just software under your account) will be able to access the disk; BitLocker only protects against offline attacks.

EDIT 2: You mentioned Chrome's encryption of cookies. Chrome uses DPAPI (on Windows), which uses your password as a key protector much like EFS does. On OSX, it uses a password-derived key and stores the password in the Keychain, which I believe is also protected by the user's password (though I may be wrong). On Linux, Chrome apparently uses the static, hardcoded password "peanuts" to derive the encryption key. Security-wise, that last approach is worth exactly "peanuts", so at least the "password" is appropriate. Also added DPAPI to the main response.


CSP: What is script-src-attr and script-src-elem?

Script-src-elem works on script tags:

<script>alert(1)</script>
<script src="/jquery.js">

Script-src-attr works on attributes that contain JavaScript:

<svg onload="alert(1)">

More information can be found in the  Intent to Implement and Ship: CSP3: script-src-attr, script-src-elem, style-src-attr, style-src-elem directives


Encrypt database records to be accessed by multiple users

The problem with direct access to the database is that users can extract large amounts of data e.g. SELECT * FROM TableName.

If you encrypt data in the database using transparent encryption, the users with access to the data see the encryption transparently or, in other words, they see clear text data. Even if they see encrypted data, they may have a view configured to see such data in the clear.

You could consider encrypting the data at the application layer. This means the data would be encrypted within the database so DBAs would only see encrypted data. The application can then decrypt and publish data depending on user privileges. This could be tuned so end users only see single pieces of data at a time rather than lists or volumes and logging could be enabled so you can identify who has accessed what data.

Then you need to consider how your key management is implemented so the encryption key used by application is not stored somewhere in clear text and is not available to any user. AES with a bit length of 128 or greater is a perfectly reasonable symmetric key to use.


client/server trust after authenticating over HTTPS then dropping to plaintext?

Is it possible to drop a secure connection for plain text while maintaining a trusted connection.

No.

  Since the server is resource limited on the computing side I would like to drop down to an unencrypted connection for game data.

It sounds like you need to do some profiling and optimizing, but I can almost guarantee that TLS isn't going to be the bottleneck.

  I am wondering if that is possible without opening myself up to very easy client or server spoofing attacks (JavaScript client).

Nope (technically it may be possible, but it's really not worth it, and there's a good chance you'd do it wrong anyway).

  Since I already can't trust the client (as it's written in JavaScript) game state is always server side and clients can only send requests which are evaluated for validity.

You're right that you can't trust the client, but not because it's JavaScript. Even if you try to make reverse engineering more difficult, you can't make it impossible.

  Although I don't have the resources, time or prerequisite knowledge to implement it, if trading was run through a series of DAPPS (On the ether block-chain) To my understanding all my concerns would be rectified at the expense of needing to spend real money on transactions.

Blockchains do have some useful properties, but there's also a substantial amount of hype. Blockchains aren't going to magically solve all of your problems.


At a minimum you would need to fill out the SAQ A or SAQ A-EP.  PayPal appears to have a partnership with a QSA, SecurityMetrics, and also covers the cost:

How do I complete a Self-Assessment Questionnaire (SAQ) to validate PCI compliance for my PayPal powered by Braintree account?

If you accept cards, however, there is no way to escape some amount of PCI compliance, and SAQ A/A-EP are the lightest.


Are regular expressions vulnerable to code injection?

If the buffer holding the regular expression is of sufficient length and regular expression parser is implemented using a regular language and not using a Turing complete language  (more accurately, using the regular-language-instruction subset of a Turing complete language), it should be impossible to do code injection.  A feature of regular languages is that very simple cases and control flow is sufficient to implement the parser.  If implemented with these simple programming tools, then hacks should be very difficult.

Please keep in mind that one of the biggest vulnerabilities is the buffer-overrun code-injection attack.  The way to avoid this attack is to write really tight and accurate code.  Check your buffer length in maniacal fashion to avoid problems.


How to securely install web applications on untrusted hosts?

Securely storing web application on untrusted server is not possible. Even if you would encrypt database on the server, you could not use server-side commands. Everything would have to be processed on the client (who has private key or password), including login, so this method is insecure as well.


Is Kissmetrics using ETags for tracking (again)?

So, are they using ETags again?

The Etag HTTP header is used for caching in HTTP, i.e. the browsers includes the given tag in the If-None-Match header of the HTTP request so that it only gets the response body if it has been changed compared to the previous access. Etag can be used for tracking but most uses of Etag care only about caching and not tracking. Thus just the existence of this header in the HTTP response is no indicator that it is used for tracking.


How to validate client side safety in a Zero Knowlegde model

My question is : is there a way to ensure the client side code authenticity to avoid executing malicious code sent by a compromised server ?

Short Answer
No, there is currently no perfect, practical way to ensure that the server doesn't go rogue and serve you malicious code without raising any obvious red flags.
Long Answer
A complete Zero Trust model is simply not practical for web/cloud applications, and as far as I know, there are no 100% zero trust web applications, only zero knowledge ones where you still have to trust them to serve you secure code. If you can't trust a server to handle your secrets, you cannot trust it to serve you secure code either. Currently, the best possible way is what you have already mentioned in your question. The developers will have to publish the code so others can audit it and ensure that there are no backdoors.  Then it lies on the end user to compare checksums and confirm that the code they received from the server is the same as the code published.
Of course, this approach is nowhere near perfect because of its sheer inconvenience. No sane human can be expected to manually check the integrity of every web page they visit. A better approach would be to have signed copies of the source code hosted on independent servers from where the browser (or perhaps an extension) would be able to ascertain whether the code it receives from the web server is the same as the publicly auditable version and hasn't been modified to include backdoors (and now you have to trust the independent server... although chances of both of them being compromised or going rogue simultaneously would be lower). But no browser currently supports this capability (and there isn't any established protocol for it either).
In the end, you'll just have to trust the developers and maintainers of whatever web/cloud service you're using and hope that if they get compromised (or are served a subpoena and gag order), someone will notice before any damage is done. The alternative is not trusting the cloud and relying on open source software running on trusted hardware.

The only source I could find that even remotely tried to address the problem of serving trusted code in a zero trust model: https://clipperz.is/blog/2007/08/24/anatomy_zero_knowledge_web_application/


Does Google have access to keystrokes on our Android device keyboard?

According to their confidentiality statement, Google doesn't collect anything from what you type when using GBoard, except the searches you make using the G button (for an obvious reason, they need the search terms to perform the search). Suggestions are based on an internal dictionary AFAIK. You can also delete the stored words at any time in the options of the keyboard app.


Consequence of using SSH when Fingerprint has Changed?

Well, there is a lot of things the "bad server" can do to you:

  How would that attack work and what could the attacker learn or do?

The attacker makes you connect to his server instead of your by modifying DNS answers or other mangling with packets. I you would use passwords, he would get your password and could connect to a real server anytime (and do the bad things there). If you are using only keys, there is possibility to forward the original server challenge to you and let you sign it, which will grant the "bad server" access to your real server. All this can be made transparent so you would also do the stuff on the real server to minimize your suspicion.

  Can he read data sent to server, can he read data sent by server?

Yes

  Can he change any data?

Yes

  Can he perform commands on server that I did not?

Yes

  Can he ever login again?

Only if you send a password. The private keys prevents this use case.

  Can he ever redo the actions I performed while I was being MitM'd?

If he does not close the connection, he can do the actions later.

The other chapter is what the "bad server" can do with your client:

If you are using X11 forwarding by default, the "bad server" has (usually) full access to your X server -- he can take a screenshots of your desktop, listen to all keystrokes, and so on.
Id you didn't patch out Roaming feature from your OpenSSH client, the server can basically force you to send some of the private keys (in some cases).
probably others ...


What is the best protocol for an organisation to make phone calls to clients, where the client is required to verify their identity?

The best way is to make it trivially easy for a customer to get to the right place through the number on their card, on their statement, on your website; more, to make it impossible for a bank department to have a number not listed on the bank website.

You can do this via a reference number, a code word, (eg, "please call us back on the number on your card, and say "fraud" as soon as our messages start.")  You need to ensure that when the customer calls in this way, they get to the right place.

You also need to train customer service reps to respect the customer's choice to call back.  Far too often, CSRs will denigrate or undercut the desire to return a call.  They might suggest that caller ID is trustworthy or even tricky to spoof.  It is not.

When I was at Microsoft, we studied this pattern, which is where an organization acts the same way a fraudster does, and results in people being unable to form a model of secure behavior.  We called this pattern "scammicry" for the mimicry of a scam.

There are additional tools you can use, including biometric voice authentication, asking questions which don't expose the answerer to identity theft, such as knowledge of recent transactions, so that calls from the bank are not so worrisome.  (Note that if there are a small number of recent transactions, then a scammer who calls can get those, and then authenticate to the bank.)


What are the roles of PSK and GTK in a WPA setting?

The PSK is the PMK, it's used to derive the PTK, and it's generated by a function called Password Based Key Derivation Function 2 (PBKDF2).

(The problem with the names PSK-PMK is that some people call the Pre-shared key the "Passphrase" like what you share to people for them to connect, when a Key is actually the 128 bits hex string)

And the GTK it's used for broadcasts encryption, since the PTK it's only for the AP and the station and no other station can listen to that, that's why you need another key.

I think I already answered some of this in here


WarGames–platforms to practice and improve hacking skills

Depending on what you call "online", a simple Google search on "damn vulnerable" will reveal the existence of freely downloadable applications of even full OS, meant for, indeed, learning all the ways software can be horribly vulnerable. One of them is Damn Vulnerable Web App, which is, you guessed it, a damn vulnerable Web app. There also used to be a full OS called Damn Vulnerable Linux; it is apparently discontinued (though of course lack of security patches was the point of it) but this question discusses replacements.

These are not "online machines" for you to hack, but you can download them and install them on a virtual machine on your own computer, which can be done for free (there are good free VM solutions, e.g. VirtualBox) and is a lot more flexible than an online target; it will teach you more since you can modify it and reset it at will.

All these resources are subject to obsolescence, modification and replacement, so the important point of this answer is to give the correct keywords for searching. And these keywords are "damn vulnerable".


Why do "Forgotten Password?" links generally reveal usernames or registered email addresses?

Yes, it is bad security practice indeed.

When using the Forgotten Password feature, the site should respond with a message: "An email has just been sent to the specified email address, if it exists and is registered within our system. Please read the email and follow the instructions."

Or simply: "Please check your email inbox for instructions on how to proceed to reset your password", since it's a safe assumption that the account reset procedure was initiated by the legitimate account owner.

EDIT: It has been pointed out that an attacker might find out whether an email address is registered in the system by trying to open an account with that address. To thwart this attack, the registration procedure must be changed too; the user should be allowed to register only after he/she verified his/her email address, as follows.

Upon entering an email address for a new registration, the site should respond with the message "An email has been sent to the email address you provided. Please read the email and follow the instructions to complete the registration, if necessary".  Then the email message would contain the steps to follow to complete the registration, or a simple warning to the user if the email address was already registered.


Is DANE the DNS-variant of HTTP Public Key Pinning (HPKP)?

While both DANE/TLSA and HPKP are somehow related to validation of the server using public keys or certificates, they address different aspects of the validation. This means DANE can not not considered the DNS equivalent of HPKP.

HPKP cares about future connections to the site.It specifies which keys will be expected in the future and thus makes it possible for the client to do pinning and protect against future man in the middle attacks which use certificates issued by a trusted but compromised CA (like in case of DigiNotar). It thus adds additional protection to the current PKI  (with a trust store in each client) and does not work without it.
DANE/TLSA cares about the current connection.It specifies which keys/certificates should be used for the current connection. It can thus work as a replacement to the current PKI. Essentially it moves the trust from the current PKI to trust into DNSSec (which is essentially a different PKI).

From the perspective of the owner of the site HPKP allows to only add additional restrictions in order to harden the current PKI system. The owner still needs to get a certificate from a trusted CA. DANE/TLSA instead allows the owner to fully control the validation process (instead of only a small aspect of it) as long as the client trusts the PKI behind DNSSec and the domain is protected by DNSSec.


Is it possible to not store passwords locally, at all?

Yes it is, you must have the computer on a domain and disable password caching. Know that if you do this you will receive the error "The system cannot log you on now because the domain  is not available." if the domain server is down.

This can be done by setting a group policy to have HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\CachedLogonsCount set to 0.


Can I use root account if every server only runs one service [Debian/Ubuntu Server]

I would agree that root can be used on your VMs much more relaxed due to the compensating controls that you specified however without knowing your setup and if this is a corporate or personal set.
My considerations as to why root on all is a bad idea:

As an attacker, automatic root account would allow me easier access to misuse the VM and put my own tools on.
If access to the server is automatic root, logs can easily be deleted/modified/read. This could include any bash history.

Virtual Machines are also commonly given a misconception around how secure they really are. For a good resource from another Infosec Stack Exchange comment just look here.
At the end of the day this is your environment and this is your risk acceptance. If the value of keeping them root out of ease is best for you I would say that is fair (judging by you being on this forum and knowledge of the dreaded rm -rf I would say you are already capable of weighing the risk adequately).
My summary would be:

If it was my home network, non-important, and weren't externally accessible outside my LAN, I would rely on my network logging and monitoring and throw access out the window.
If this was any other situation (running accessible services, corporate use, R&D, sensitive PII, etc.) I would DEFINITELY enable least protection privileges and check those SUID bits and GTFOBins.

Hope this helps.


How can I send an email from my laptop anonymously?

I have a vpn, if I connect it and create an email account while connected to the vpn, and then send the email to the desired recipient, what other levels of protection/anonymity am I missing?

If you create and use the email account through an anonymizing service (your VPN) and use the service correctly, there is no straightforward way to de-anonymize you. Of course, the usual side channels apply. Your ISP might correlate the time of your VPN usage, someone might recognize your writing style, your browser can be fingerprinted, etc.

If you use Google Chrome through a VPN with GMail, they might also employ additional means to be able to exactly identify your browser instance and could theoretically correlate that with a point in time where you use the same Chrome instance without a VPN. In contrast to that, the Tor browser developers went to great length to prevent various ways of fingerprinting.

  If I use Tor then if I send an email to an outlook or gmail account then would it go to their spam mail?

No. If you use a GMail account through Tor and send an email to an Outlook account, that's a connection between Microsoft's and Google's mail servers. For the mail delivery between the providers it doesn't matter how you connected to GMail in the first place.

  And can I access gmail or outlook through Tor?

Generally, yes. But GMail and Outlook might employ anti-spam measures to cope with fake accounts and hence might block some Tor exit nodes or VPN servers. You'd have to try out for yourself.

  I want to know to what extent my VPN will help me from having my IP address traced back.

That's too broad to answer in a single post. We have plenty of questions on VPN security here that you might want to have a look at. Also see: Differences between using Tor browser and VPN


What are the security issues of having all services (web, smtp, dns) on a single machine?

Other then the amount of resources all these services on one machine will take up, you will need to worry the most about one of them being compromised.

In this situation, when one service is compromised they all are. Any attack on one of them is an attack on all of them.

If you have no other choice and have to have all of them on the same machine, make sure to harden the machine correctly (user restriction, different password and usernames for each service, limit what your services talk to and so on...).

  We can also assume I have a backup DNS and mail server, so if the machine goes down, I can switch to the backup services.

That's nice but do you really want to get to that point? And what if it was an exploit that can be used also on this version of your machine/service? But do make sure to always have a backup, just don't use it as an excuse for weak security.


Why POODLE vulnerability has for each byte a probability of 1/256 to get it in plaintext?

It is the job of an Initialization Vector to cause the same message to have a different encrypted value when encrypted with the same key. An IV is essentially a nonce used to salt a message.

As for why 1/256, that is the maximum possible values in a byte. A byte is a number that can range from 0 to 255. Including 0, that is 256 values.
So a 1 in 256 chance of getting the correct next value of a byte, is the same as if randomly guessing.


Embed root certificate in software library

I am assuming your question is about the certificate of the server which the library is going to communicate with.

It's secure in the sense that it will be prevent the application using the library from inadvertently connecting to a server which is not trusted by your library. But it will not prevent malicious intent by the user of the library - i.e. the application can replace the certificate stored in your library. But this is the case even with browsers etc. The user of the browser can ignore warnings by the browser which says that certificate of the site you are connecting to isn't trusted.

There isn't any way to prevent some one who wants to connect to a wrong site as long as the wrong site allows him to connect.


How can WhatsApp do both targeted advertisement and end-to-end encryption?

Your WhatsApp account is linked to your Facebook account. They know lots about you from your Facebook activity, and can use that to direct targeted ads at you on WhatsApp, without knowing anything at all about the content of your WhatsApp messages.


Protect an application that uses internet from packet sniffing

If everything is made through HTTPS, all your application have to do is ensure the certificate is correct and valid.

Man in the middle attack can only decrypt HTTPS traffic by ruining the original certificate and issuing a [generally] self-signed one to the local peer communication.


How to inspect TCP Header -> Optional Data with Snort?

Snort don't support to check tcp header length.

But if snort connecting to database, it can store optional data of ip and tcp.


How do I ensure data encryption on Samba transmission on *NIX systems?

Use Samba 3.3.x+ and set server signing = [auto|mandatory|disabled] in the Global section (disabled by default). Share level SMB encryption is auto by default. This has been tested with WinXP/Win7 and AIX 5.3 running Samba 3.6.7. SMB encryption became available in Samba 3.2 but server signing did not appear until 3.3. These are required for Win7 clients configured to Microsoft's security recommendations (NTLMv2 and 128 bit encryption).

See: http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html


Can I tell which applications embed Internet Explorer at a command prompt?

There are lots of libraries that relate to the Internet Explorer functionality, and it's probably the case that anything making use of it uses others that I don't know.

Two that are signs, though, are definitely shdocvw.dll and mshtml.dll. If you see an application loading either of those libraries, you can feel pretty comfortable that it's making use of IE. Take a look at MSDN's About the Browser article.


Is it okay to only provide clickjacking protection on the login page?

The answer is simple and straight-forward:

Having clickjacking protection only on the login page only protects the login page.  The rest of your site is still vulnerable

It sounds like you have a bit of a misunderstanding, and are hoping that because the login page is clickjacking-protected, someone can't use clickjacking to attack your site.  Unfortunately that is not the case.  Clickjacking (typically) relies upon using the credentials of an already-logged in user.  As a result, there is no need to target the login page with clickjacking.  Rather, you target any other page that has a sensitive action.

In fact, the login page is probably low on the list of pages that need clickjacking protection.  The reason is because you can't use clickjacking to enter a password, nor would an attacker know the user's password to log them in even if it was possible.  It might be possible to use clickjacking on a login page to login a user if the browser stores the password and suggests it automatically, and then follow that up with a clickjacking attack on another action on the site, therefore building up an exploit from multiple clickjacking attacks.  In general though, using clickjacking against a login page is probably not an interesting target in-and-of itself.

As a result, you pretty much have things backward: if you had everything but your login page protected from clickjacking, you'd probably be fine.  If you only have your login page protected from clickjacking, then your clickjacking protection is useless.


Is PGP or S/MIME useful when both servers are self-controlled?

With regards to encryption and preventing a 3rd party from viewing my emails (and ignoring validity/signing), is encrypting an email via PGP or S/MIME useful when I control my server and my recipient controls their server?

In practice: No, but you need to make sure many other elements of the network aren't fooling you. I will concentrate on the transmission here. End-to-End encryption gives to extra security on top of other elements, described here. If some elements fail, GPG still protects the content of your mails.

First, you want to make sure, you can contact the right recipient’s server. To do that, your sending mail servers does a DNS-Lookup for the MX-Record of the domain. Then the resulting FQDN has to be resolved to get an IP. This is the first possible attack vector, as the used DNS-Server must be trustworthy and not controlled by the attackers. Additionally, the DNS can also be fooled. You may have a look on DNSSEC or DNScurve, both want to ensure, the answer from a DNS is authoritative, as the DNS protocol is completely unencrypted and tampering is very easy.

A possible solution is to overwrite the domain -> MX and A lookup on your server, by specifying a custom transport in your mailserver explicitly ("use this server to deliver mails to that domain").

The next possible problem is, you can't be sure you're talking with the real other side, even with SMTPS (SMTP over TLS) or SMTP+STARTTLS, as usually server certificated are not checked. Thus, the sending server must check the other's server certificate, and also the other way round: The receiving server has to check the client certificate of the sending server, because otherwise the receiver can't be sure, the trusted server sent the mail. Also make sure the connection can't be downgraded to plain SMTP.

As CA's and the PKI-System also have their problems, certificate pinning is appropriate. Others already brought up the issue of backups.


What does "unknown" status in nmap mean?

The "unknown" port status doesn't come up very much, but it can happen when you try to scan your own IP (or 127.0.0.1) on Windows. This is because Windows does not have raw socket support, so Nmap's SYN scan packets have to be crafted at the Ethernet level. This just doesn't make sense for a localhost connection, and there's no way to do it.

To get valid results, you should add -sT to your command line. This selects Nmap's TCP Connect scan, which will succeed. Alternatively, if all you need is a list of open ports, the netstat utility will give you exactly what you need.


Security concerns with uploading an image

As schroeder mentioned, you may have neglected some detail here, which makes your security group nervous.

There are a number of classes of attack the security group may be concerned with.  Just a few for example that might be worrying them:

File Upload - you don't mention how this is handled.  Some questions to consider - Is there enough temp space on disk, what happens to the temp file after the upload, can the user specify the file name, how is the file size determined and enforced?  Any and all of these could be vectors for an attacker.  The most obvious one would be to tell the server the file is one size, have the server allocate that much memory, then send something bigger and corrupt the server's memory, possibly getting code execution.
Store in the database - can the user specify a file name, or is their username added to the database table, and if so, what does the SQL to store those values look like?  Are you sanitizing the input, or using stored procedures, or does you code do something like (pseudo-code) "db.store($picture_file, $name, $table_users)" ?  In the latter case, that's very bad, and likely to expose you to SQL injection . Not strictly speaking a "virus" but something your security department would care about.
Upload authorization - Could someone else upload a file on behalf of a different user (e.g. could they guess a user number in a URL parameter)?  Or, you mention XSS.  What if the user is victimized by some other site via XSS to upload a payload to your site?
AIX OS resistance - No OS or specific flavor of Unix is 100% safe.  Assume the attacker is out to get you (or your user) and has done their homework and has crafted AIX-specific shell code.

Basically, what it comes down to is that we don't have enough details for a thorough security audit of the feature, but your security team does.  The details matter and the list of the technology stack provided tells us nothing about the vulnerability profile of your specific application.

One can make a reasonably secure "image file upload" function for a service, but nothing in your initial post suggests excessive paranoia on the part of your security group.

Talk to them, find out specifically what they don't like about the feature, and work with them to provide the functionality you want in a way acceptable to them.


It depends on who provides OTP. If the application is designed / implemented badly, it can accept OTPs without expiration. If the application is designed / implemented correctly, it will have expiration time for each OTP.


What's the difference between SSLv3 being deprecated and SSLv2 being prohibited?

Both documents intend to prohibit the use of the respective protocol and use the same RFC 2119 as a reference for terminology.

RFC 7658 (the one titled "Deprecating...") specifically says:

  Security Considerations

  This entire document aims to improve security by prohibiting the use of a protocol that is not secure.

Both documents were written in different times, by different teams and both are classified as "proposed standard". Moreover, RFC titles seem not be standardised and no BCP document of IETF mentions how the titles should be formed.

The documents should be considered as a whole and their interpretation and application should extend beyond their titles.


Can lack of certificate pinning be considered a vulnerability?

The use of certificate (or public key) pinning can be considered as a good practice for defense in depth

HPKP can be considered good only when it is carefully designed and implemented. In theory, public key pinning is more secure because it reduces surface attack by limiting a number of certificates (trust anchors) the application trusts. Biggest issue with public key pinning is certificate management. This is where most HPKP stories end.

If you trust only particular certificate/public key, it is irrevocable. If key is compromised, the application becomes immediately vulnerable, because you it is hardcoded in the application. The same story is when you simply replace the certificate. You will have to update the application, upload to app store and wait until clients update the app on their devices. Security is always a tradeoff between security and flexibility.

Better solution would be to ship a set of trusted anchors (trusted root certificates) your application trusts and configure certificate validation logic (built-in in OS, do not roll your own crypto) to use only these roots as trusted anchors. That is, chains still must be validated, revocation checking must be performed even if you use HPKP. This approach assumes that CA key compromise is less likely than SSL server key compromise. In this case, you have better security and flexibility. However, you still have maintain the list of trusted anchors and update them when necessary (because you no longer rely on system trust store).

Again, it is in theory. In practice, most app developers don't care at all and their HPKP implementation is worse (more vulnerable) than standard system trust store.

Worth reading on HPKP: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead.


Rogue network printers as an attack vector in windows

Windows only automatically installs drivers that have been digitally signed. Unsigned drivers, drivers that have invalid signatures and drivers that have been signed by untrusted publishers are not installed automatically. Instead, if the user is an Administrator, they are given a warning message informing them that the driver is unsigned or has been altered (and then are given the option to quit installation or continue anyways). Standard users are not given any option and the driver is not installed.
So to successfully install a driver the way you suggest, you would either have to compromise the private key of a vendor that Windows trusts, or somehow manage to get your own certificate onto Windows list of trusted publishers.


How a DOS TCP packet different from normal Packet?

It doesn't differ, really. A denial of service usually involves a flood of packets, rather than a single malformed packet. There were a few attacks "back in the day", like the Ping of Death, which exploited vulnerabilities in the packet handling code on the target system, but these are (largely) a thing of the past.

In general, with a DoS attack, you'll find that thousands of SYN packets are sent in order to starve the system of resources. This can prevent legitimate users from connecting, since the system is trying to serve the fake clients.


What makes the Blackberry device and network more secure?

How dare you! How dare you question the most secure mobile platform available to mankind! My attempt at humor there.. now to a serious answer before the mods attack. Blackberry has some whitepapers regarding security here: http://us.blackberry.com/ataglance/security/

I would argue the network is not RIM's strongest asset. Corporate and government adoption of the product due to the level of control they have over the devices is RIM's strongest asset. MDM is a hot topic now, but people seem forget that RIM has been doing it for 14 years.

Unfortunately for RIM the pendelum has swung away from corporate control towards the "bring your own device" philosophy, and with good reason. Android and IOS offers a better user experience.


How to hide the sensitive data from the developer of the application and the DBA of the database

You have different options, consider that depending on the regulations what you want to do may be mandatory (i.e: Spain).

This is as simple as creating a database with fake info but with the very same structure.
Change the names of the employees in the database (and other ids), let them develop and then change them back.
Make the developer and the dba sign a non-disclosure agreement and let them work with the original db.

I believe that the first option is the best, populating a database is an easy thing using an script or similar and they don't need to access the real information. The third option, if you are afraid only about regulations, is the easiest.

--- After the clarification I add:

You can use any method to store the data in the database, I believe that the easiest way is not using public/private encryption but using a normal password with bcrypt or similar (this will have less complexity and will prevent you from managing keys).

The problem using a password is that the data will be crypted with just one password and all application users may have to share it.

I believe that encrypting the information inside the database is not a good solution since it has many implications, what I would do is limiting and logging the access to that database and choosing a dba for it in which I can trust.

The developer, simply, doesn't need to access the real data, you can build your own database for tests and development.


What are the security risks when users upload their HTML and javascript to AWS S3 and the content is used in a webapp?

No, they can't "hack the central system" with HTML/JS (and definitely not CSS). If you gave them PHP access, you'd need to be careful, but normal HTML/JS/CSS is harmless for your server. Not so much for visitors, though. A malicious uploader can do stuff that will harm visitors to the site.

There's one thing that you may need to be careful about in this regard. It really depends upon your setup.

Let's say that the user-provided code is hosted on www.mydomain.com. Let's say that www.mydomain.com also has a login feature on the same server. As a real world example, lets say you own Facebook and are allowing folks to host HTML/JS files to a subdirectory (e.g. www.facebook.com/username/index.html or something similar). Now, if I visit www.facebook.com/eviluser/index.html, his JS has access to my account. Using AJAX, he can wreak havoc with my account. If there are any other websites with Access-Control Allow-Origin for www.facebook.com, and I am logged in on those as well, his JS can wreak havoc (via AJAX) there as well.

Basically, you need to be sure that all AJAX written by the user can do no harm to a visitor. The easiest way to do this is to host it on a domain where there is no "login" functionality whatsoever; so malicious JS has no session to abuse. Or prevent same-origin AJAX (Which probably isn't possible).

Another thing you must be wary of is your users using clickjacking/etc and getting your site blocked.


Accesssing cookies of another domain using Iframes and Javascript

Same Origin Policy ensures that you cannot read or modify the content of a page with different origin. In case of the iframe this means that the parent frame can fully replace the iframe (and thus changing the origin) but it cannot read or modify the contents of the iframe has a different origin.

Thus reading a cookie cross-origin from an iframe will only work if the content of the iframe explicitly communicates with the parent frame (like with postMessage) to share the cookie value. Usually this is not the case with unrelated origins but if you find a XSS attack at the iframes origin then you might be able to trick the iframe into sending this cookie to the parent frame.

Note that X-Frame-Options is unrelated to the same origin policy. It is only used to define if a site can be put into an iframe or not. This is important to defend against Clickjacking or other UI-Redressing attacks.


Usually, signature generation time is more critical, because signature generation entails using private keys, which must be protected, and therefore used in shielded system which trade security for computing power. E.g. smart cards.

In an overall system, it may happen that RSA is better than ECDSA, or the contrary. For an ad hoc network, we might expect that components authenticate each other, which implies that the relevant measure is the sum of the signature generation time and the signature verification time. For that sum, ECDSA wins over RSA. It also offers shorter signatures, which is a great asset on low-bandwidth networks.


Mainstream media reporting is not the place to go for this kind of stuff. If you look up Symantec's report you'll get a lot more detail. They claim that WannaCry is probably authored by an outfit called Lazarus Group, and specifically claim that this malware does not fit the pattern you might expect from a nation-state effort.

https://www.symantec.com/connect/blogs/wannacry-ransomware-attacks-show-strong-links-lazarus-group

In particular, they say:

The networked command & control infrastructure between this attack and another Lazarus attack is similar, using some of the same IP addresses.
The softwares handle network buffers and network communications in identical fashions, specifically they use some of the same constant values.
The softwares have a large set of repeated strings in the binary.
The softwares generate cryptographic numbers the same way.
The softwares have at least one shared function between them.

What this means is that these two softwares share some connection. Either the same group is responsible for writing them, or they're written by two groups that share code and network infrastructures, or it might be the case that someone has gone to a great length to make it look as though there is common authorship when there is not. It's not practically possible that there is no relationship and all of the above just just total random chance.

Some folks have tried to claim that Lazarus Group is a North Korean nation-state group, but there's not really any evidence to support this. Some of their early attacks were against the South Korean government and Sony, but this is pretty circumstantial. They have attacked non-South-Korean and non-Japanese targets as well.


So the answer was obvious I suppose but I still don't know how to work around this.
When the target machine was requesting a site such Facebook.com it was doing it over HTTPS obviously. Which I guess meant it expected the site returned to accept a HTTPS connection.
This means that if I wish to DNS Spoof and forward the target machine to a different site that (at least for the moment until I figure out a work around) it needs to accept the same protocol that was initially requested.
To test this theory I found a site that allows HTTP connections (MSN.com) and I instead returned my blog. This worked swimmingly.
Results
So the short answer to the above problem was that I was attempting to forward the target to a machine that didn't support HTTPS though that's what the target machines initial request was for.
By using a site that accepted HTTP requests I was able to confirm this was the problem.


Does the Dreamy Smurf tool really exist?

It is impossible to turn on a device that is COMPLETELY powered down, however I have heard of some bugs that can prevent the device from completely powering down; thus making it possible to wake them from the fake "shutdown."

Sources: Personal experience and Link


Security of in-house data storage vs. cloud storage

It will depend on the actual threats and the relative importance of the 3 pilars of data security: Confidentiality, Integrity, Availability.

But here are some pros and cons:

Cost: you are changing buying for renting. Depending on your economic model, and cash flow, one may be more interesting than the other, or may be a mix...

Availability: local storage will require backups, and the company will have to setup and run backup procedures and recovery tests. You should considere the Mean Time Between Failure of the storage system, and the Maximum Tolerable Period of Disruption in your recovery procedures. All that comes out of the box with a cloud solution - provide you choose a serious provider.

Confidentiality/Integrity: if someone can enter in your internal systems, he will be able to access to your data be it local of in the cloud. But You cannot be sure of who really can access data when it resides in a cloud. So a cloud solution will add risks here. Whether they can be accepted depends of the sensitiveness of the data


Is it possible to exploit this code?

Yes.

  How can an attacker exploit this?

Path Traversal Vulnerabilities allow an attacker to choose a file that is not intended by the developer.

For example, your program has the path "C:\\Users\\kutrivedi\\Desktop\\Ref\\" + input + ".txt" hardcoded. If I entered foo as input, then the resulting file would be C:\\Users\\kutrivedi\\Desktop\\Ref\\foo.txt.

Of course, I could add more than just one word, such as foo\\bar, which would result in the following file being read instead: C:\\Users\\kutrivedi\\Desktop\\Ref\\foo\\bar.txt

So just by adding \\, I can traverse deeper into the file structure.

  Can an attacker traverse the file system up?

I can do that too, with the pseudo-directory ... Every directory has a pseudo-entry called .., which points to the parent. As such, if I enter ..\\foo, then the following path is created C:\\Users\\kutrivedi\\Desktop\\Ref\\..\\foo.txt, which will be resolved to C:\\Users\\kutrivedi\\Desktop\\foo.txt.

For example, if my payload is ..\\..\\..\\..\\foo, then I would now read C:\\foo.txt.

I could go further and print arbitrary files, as long as they had a .txt extension. Since this code was presumably written in Java, and Java does not terminate strings with a \0 character, there is no easy way to terminate the string earlier to skip the extension.

If, however, your programming language was built on null-terminating strings, my payload could read arbitrary files too, as long as the process had permission to read them:

..\\..\\..\\..\\Windows\\System32\\config\\SAM\0 will result in C:\\Windows\\System32\\config\\SAM.

  How can this be fixed?

The easiest way is to use a library or built-in framework, which deals with paths. Most libraries have checks to see if something is inside or outside a directory structure, so you can use those checks to see if the payload you are getting is trying to access a file it shouldn't.


Are cars with keyless proximity-based entry protected against range extenders?

I suppose this fall backs to active RFID type of communication issues and, maybe 1-2 years ago, I read an article on the subject (sadly I do not remember the reference now). Researchers tried to authenticate under the following condition:

The victim bearing the genuine RFID token was in some crowded public place (subway, ...),
Attacker A goes near the victim (no need to steal the token), he bears an RFID tranceiver linked to a mobile phone,
Attacker B is near the door to open, having also a mobile phone and an RFID tranceiver.

Here is a quick representation of the communication path established between the RFID token and the RFID lock:

Genuine RFID token <--> RFID tranceiver <--> Mobile phone A <--> Mobile phone B <--> RFID tranceiver <--> RFID lock

Thanks to this system, the researchers manage to extend the RFID range to unlimited. However, the issue they encountered was, as you mentioned, timing issue making this attack practically not doable with current technology (ie. up to 3.5G), however they emitted some worries on the subject with technology evolution which would fatally come up with this timing issue.

So, to answer your question, technically the attack is doable, but not practical yet. However, if I were to wear such a key and would have such safety concern, we see more and more faraday pouches designed to prevent such issue (some are even integrated to bags and jacket pockets, a discussion on the subject is here).


Why are full port scans more susceptible to being logged than half-open port scans?

Half-open scans are purely dealt with by the operating system, which is not likely to log anything unless a firewall like iptables is in place.  Once a full TCP handshake has taken place, however, the operating system hands the connection off to the application that's listening on that port, and the resulting hangup is likely to cause the application to log an error.

In short, half-open connections are quieter because they stay behind the scenes with the OS.


How can I improve and secure automated signing?

Typically, you have two vectors here.

Loss of the Private Key
Unauthorized use of the Private Key

Generally, some hardware backing is recommended to address #1, such as an HSM, SmartCard, or other physical crypto device.

These devices also typically have some from of access control, ranging from IP ACLS with passwords, all the way down to a pin with small retry counts.

As a general rule, you need to be restrictive on what can access the PK for signing, for example, if jenkins builds your software, then signs it, only allow jenkins processes to access the PK, additionally all signing could be performed on a seperate jenkins slave, which is as isolated as possible from everything else.

However, as we all well know, damage control is almost as important as the attempts made to prevent damage. One should ensure he/she has a way to revoke the signing key should it become compromised, and plans to replace and transition cleanly.


What could be the order of these ciphers following as first criteria the security and just then the performance?

Security: if you don't do stupid things like using a 512-bit RSA key, these cipher suites are all equally secure: they are all very far in the "cannot break it" zone. So that's a meh. You cannot say that one is more secure than any other.

With an exception though: the "ECDHE" suites use an ephemeral key pair for actual encryption; since the corresponding private key is never stored in a file, this grants a nifty property known as Perfect Forward Secrecy. Basically it makes communications immune to attackers who steal a copy of the server private key after the fact. PFS looks good in technical audits.

Performance issues exist only after having been duly measured. As Knuth said: Premature optimization is the root of all evil. So you should not ask such questions; you should try it out and measure. In any case, answer will depend a lot on the context: involved machines, bandwidth, usage patterns...

Short answer: won't matter.

Long answer:

The "GCM" cipher suites use GCM; the non-GCM cipher suites use AES in CBC mode and an extra HMAC (here, with SHA-384). Performance issues depend on the involved systems:

On small 32-bit systems (embedded ARM...), the MAC part of GCM will be expensive, but so will SHA-384 (because 64-bit computations...); I'd guess a tie.
On PC, AES cost will dominate;
... except on very recent PC with AES-NI, where AES is very fast, and so is GCM.

So the GCM cipher suite should, usually, be a better bargain. However, it takes a lot of bandwidth, or a very small CPU, to actually notice the difference. Even without AES-NI, a normal server has enough juice to do SSL at full gigabit bandwidth, with CPU to spare.

For the asymmetric cryptography part:

The ECDHE suites imply on the server an (elliptic-curve) Diffie-Hellman and a signature for each full handshake, whereas the ECDH cipher suites require only the elliptic-curve Diffie-Hellman, and half of that one is already done.
... But a normal PC will crunch through thousands of those per second and per code, so this very rarely matters.
... Especially since normal SSL clients reuse SSL sessions, which means that the asymmetric cryptography occurs only for the first ever connection of the day from a given client.
ECDSA signatures are faster than RSA signatures.
... Depending on key sizes, of course.
... But for verification, this is the other way round.
... And, again, it takes an awful lot of new clients per second for this to actually matter. A normal PC will do hundreds of 2048-bit RSA signatures per seconds, thousands of 256-bit ECDSA signatures per second.
ECDSA signatures are shorter than RSA signatures, so this saves a bit of network (but, again, only a few dozen bytes per full handshake).
DHE and ECDHE cipher suites also imply a few dozen extra bytes per full handshake.
DHE is like ECDHE but without the elliptic curves. You need it to use bigger mathematics to achieve the same security levels (2048-bit modulus instead of a 256-bit curve point), so it is like RSA vs ECDSA: a bit bigger, a bit slower, won't matter in practice.

So, really, you will not make a useful distinction based on security or even performance. In fact, you are already making a fashion statement, by insisting on AES-256 (instead of AES-128) and SHA-384 (instead of SHA-256). You may as well keep it on and bring it to its logical conclusion: use as much GCM and elliptic curves as possible ! This will grant brownie points from impressionable auditors.


How to find the OS of the target machine

If you can send packets to the target machine, use nmap -O, which provides OS fingerprinting.

If you can eavesdrop/intercept network traffic with the target machine, use pof, a tool for passive OS fingerprinting.

You didn't provide much information about what are your constraints or why the standard tools (like nmap or pof) didn't work for you.  Therefore, I'll provide some generic advice: I suggest you look into OS fingerprinting.


What is the background of the Reference Counter Overflow in Microsoft TCP/IP (MS11-083)?

The vulnerability could allow remote code execution if an attacker sends a continuous flow of specially crafted UDP packets to a closed port on a target system.
  https://technet.microsoft.com/en-us/security/bulletin/ms11-083

So while a huge amount of UDP packets with all bits set to zero may result in a crash, it is unlikely that it will result in code execution. They need to contain content specifically written to exploit the issue.

It is an reference counter overflow according to the same Microsoft source.

What is a reference counter?

When a program allocates a block of memory, a reference counter may be used to manage it. Whenever a part of the program code wants to access it, the counter is incremented. Whenever this part of code is done working with the memory block, the counter is decremented. When the counter reaches 0, nobody is interested in the memory block any more, and it is freed.

What is an integer overflow?

Integers are numbers used for counting. They have a fixed size in computer memory. For example 32 bit or 64 bit. So unlike integers, you know from mathematics, there is a largest possible number. Adding 1 to that number will either result in a very negative number or 0.

In other words, if you add 1 again and again, you will end up with 0.

What is a reference counter vulnerability?

A reference counter vulnerability is usually caused by a program path that fails to decrement the reference counter. The attacker is therefore able to increment the counter again and again.

As a result, he can get the counter to 0 and beyond (see previous section). After he got the counter to overflow and ended up at 1 again, he will trigger the normal program path that will decrement the counter.

Now the counter reached 0. 0 means, nobody is interested in the memory block anymore, so it will be freed.

What is the error path in this context?

The program path that fails to decrement the counter is used when there is no service listening on the UDP port.

It is easy to conclude that an open UDP port is required for the final decrement to exploit the issue. Microsoft, however, did not mention this. Furthermore they  stated that the Windows Firewall offers no protection against this bug. Therefore the conclusion is likely wrong.

Why is freeing used memory blocks a bad thing?

Freeing memory just means that it is marked as "available". Someone else, who requests a block of memory, may therefore get it. But the original program still thinks, it owns the block and can use it as it wants.

So we end up with two programs using the same memory block without being aware of each other. This obviously leads to data inconsistencies.

With a bit of bad luck and special crafting, one of this programs may do bad things to the other. Imagine that the other program is storing program code, pointers to program code, or trusted data that will result in pointers to program code in this memory block.

Is this a real risk?

Yes. It is not easy to exploit and sending a such a huge amount of UDP packets over a slow Internet connection will likely be noted. But it is real issue that needs to be patched.


The ciphersuite being used is shown in the reply section here: Cipher:       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [0xC02F]

The version of TLS being used in shown in the same block at the top, here: (TLS/1.2)

So, you are using TLS 1.2 with an RSA certificate for authentication, ECDHE as the key exchange mechanism, the data is being protected with AES-128-GCM, and SHA-256 is the PRF.

However, this does not answer what appears to be your real question, which is SSLv3 disabled?  You cannot tell that from this connection, only that you did not use SSLv3 for this connection, and that your browser (and this server) can successfully negotiate a TLS v1.2 connection.

If you want to ensure that SSLv3 is in fact disabled, you need to attempt to connect to a server that does not support any version of TLS, or in otherwords, anything higher than SSLv3, and ensure that the connection fails.  The fact that you can negotiation a TLS connection tells you nothing about whether you can or cannot connect to a site using SSLv3.

A simpler option:  Use a tool like the SSL Labs browser tester which will immediately tell you what your browser is capable of, and give you a definitive Yes or No on whether SSLv3 support has indeed been disabled.


Why is the Store Passwords with reversible encryption option even there?

Yes, that option is there mostly for legacy software/hardware purposes to support CHAP authentication.  You shouldn't enable that setting otherwise.

The reason passwords have to be encrypted, rather than hashed, on the server is because the CHAP authentication protocol was designed with a different threat in mind.  They were more worried about the password being sent over the network in plaintext (these were the days of telnet, ftp, and http so that was an accomplishment).  So they implemented a process by which the server sent a random challenge or nonce string to the client that needed to be hashed by the client along with the password.  This prevented people from sniffing the password off the network during transmission.

But since the server needed to calculate whether the client response was valid it also needed access to a plaintext copy of the password to hash with the challenge.  So they encrypt the password to allow the server to decrypt it temporarily and make this comparison using the plaintext.

Today when newer protocols (like NTLM or Kerberos) want to implement this same network level of protection they just calculate the hash of the password first on the client before making the other transformations.  That way they only need store a cryptographic hash of the password on the server.


Why is 128bit AES considered very strong but 160bit SHA depreciated?

For hash functions (like SHA-1) being used to sign SSL certificates, the security is completely undermined if you have successful collision attacks.  Due to the birthday paradox, a N-bit hash function effectively provides about N/2 bits of security against collision attacks.  That is a brute-forcer can create collisions for a N-bit hash function after generating about 2N/2 potential strings to hash.  Hence an 160-bit hash function provides about 80-bits of security against collisions (meaning it takes about 280 effort to generate a collision via brute-force).

For a block cipher (like AES), you use a N-bit key that maps a block of text (128 bits in the case of AES) into a block of ciphertext in a reversible way if you possess the N-bit key.  Hence, to brute force a block cipher with an N-bit key (and no other vulnerabilities), you need to try about 2N possible keys until you find a key that transforms the ciphertext into the original message.

Thus (without looking at any specific flaws in the two algorithms), a block cipher with a 128-bit key is much stronger (which takes 2128 effort to brute force) than using an SSL certificate signed with a 160-bit hash function (which takes 280 effort to find a collision and completely undermine the security).  In fact it is roughly 248 ~ 281 trillion (1012) times more secure.

Explanation of why collisions break SSL certificates

Basically, an SSL certificate consists of some plaintext information p and a signature S provided by a certificate authority.  This plaintext typically includes the name of your organization and your domain name and similar information.  If you want a new certificate, you then submit this information to a certificate authority (CA) that popular web browsers  intrinsically trust.  The CA checks your information (e.g., they verify you own the domain, by say emailing a code to the email address listed in the DNS records for that domain, OR you pay for an extended validation certificate and the CA does more checks that you are the organization you say you are).  If the information checks out, the certificate authority will agree to sign it and issue you the signature to complete the certificate.  The signature consists of hashing the plaintext information H(p) in the certificate and then using the CA's private key (K_priv) to encrypt that hash (S = E(K_priv, H(p)).  Then anyone can use the corresponding public key of the CA (K_public)  (and your operating system and/or web browser typically comes with a list of public keys of trusted certificate authorities) to decrypt the signature to find H(p) = D(K_public, S) and verify that the signature matches the hash of the plaintext information in the SSL certificate.

Thus if you generate roughly 280 different plaintext messages p (some in the form needed to be a certificate for a domain, some in the form of certificates for intermediate certificate authority), it could be possible to find a pair of two messages p1 and p2 that collide.  If say p1 identifies a randomly changed domain (sgnjnjrafaftjhyqsv.com) that you can easily buy (or you vary subdomains of domains you already own like sgnjnjrafaftjhyqsv.blah.com), then you can verify ownership of p1 to a CA and you can get a CA's signature of p1. Since the hashes match H(p1)==H(p2), you can take the signature from p1's certificate and use it with p2 to generate a valid certificate.  If p2 for example was an intermediate certificate authority that allows you to sign other certificates, you could then use that intermediate certificate authority to sign any certificate you want (and could for example spoof any website you want -- at least ignoring other protections like certificate pinning).

For reference, this attack was successfully used to create fake intermediate certificate authorities against MD5 (128-bit hash) signed certificates around 2008.  Note, ignoring specific flaws in the relevant hashes finding a SHA-1 collision is only about 65,000 times more difficult than finding one in an MD5 hash.  With the cost of computation decreasing, it is believed to be feasible for sophisticated attackers to collision attack SHA-1 and undermine SSL security.  Using a 256 bit hash (like SHA-256) is about 18 billion billion (18 x 1018) times more secure than a 128 bit hash (like MD5) against collision attacks (again ignoring specific flaws in the hash functions).


Groupon SG is Storing Customers' Credit Card Information

I don't believe there are any actual LAWS in place to prevent storing credit card details aside from those meant to protect against fraud.  However, the PCI-DSS certainly takes a much harder stance against the storage, transmission, and processing of credit card details.  The penalties are against the merchant, and can be quite severe, so there are industry-based sanctions to deter against failing to adhere.

If you read the PCI-DSS compliance text, you'll see that a merchant -- with the proper infrastructure and security systems in place -- is allowed to store the full CC#, expiry date, and name on the card.  They CANNOT store the CAV2/CVC2/CVV2/CID under any circumstances (not even in an encrypted manner).  See section 3.2.2 of the PCI SAQ-D (which is the most general form of the PCI-DSS assessment questionaire).

Are you sure they are storing the digits on the back of the card?  This is a very blatant violation.  Both VISA and MC have methods to report merchants which do not adhere to PCI-DSS and as global brands, they are enforced in Singapore.


You should focus on both, but not only, monitoring and preventing is part of single system where there are also established procedures on what to do if the data is leaked or lost.

Monitoring (e.g. data availability, data leaks via audits)
Taking action (procedures) in case of breach or data loss

Sending notifications to interested parties
Restoring from backups
Failing over to another node
Failing over to another location
Etc

Preventing

managing access (granting users appropriate permissions)
ensuring policy (including backups and access policy, e.g. group policy)

Hope this helps.