Is sending authorizing links through e-mail a vulnerability?

The problem with this is that in current practice, e-mail is not really a very secure channel to send this sort of information. There isn't much of a way around this, short of convincing the overwhelming mass of humanity to drastically change its e-mail habits. That's probably never going to happen, so we have to live with it as best we can.

If an "authentication" link expires after a short time, then the risk of a leak is minimal. It is very unlikely that anyone will get into the e-mail account between the time the e-mail is sent and the time the user sees it. It also helps if, once the link is clicked, it immediately expires, because this makes the window of opportunity even shorter.

For such purposes as password resets, this is typically considered "good enough." In these cases, the window of opportunity for an attacker is very short, because the user had to deliberately trigger the link's creation, and we told him to check his e-mail. Chances are, he'll check it and click the link within minutes. That's what we want.

But the longer that link stays active, the greater the risk that someone else will see the link first. If they use it, you're trouble, because you have no way to know that this is not the user you intended the message for. That's the security-based reason why it's not a good idea to use a long-term authentication link.

There's another, more pragmatic reason: how will the user remember which link to use? If the user has to memorize or type his own authentication URL, that's at least as difficult to use as a password, plus the user will need to type it into places where it won't be hidden. If we rely on the user to make a browser bookmark, then as soon as the user has to deal with multiple machines (barring browser sync mechanisms, which present their own problems), the bookmark gets lost. If the user has to go through his e-mail each time he wants to log in, that's another user/pass dialog to go through, and even though it's not one we have to worry about, we still haven't saved the user any time.


WebDAV automatically attempting to connect remotely because of DFS namespace?

I believe that Win 7+ will automatically attempt to connect to a WebDAV service if it's link formatted as you have it, thinking that the service is on a remote system somewhere. (IE under a mapped drive doing something like \\example.com\folder\ will trigger MS to look for external services in that domain using WebDAV)

Method 1

If you have no WebDAV service for external users, just filter out all WebDAV traffic. Let it get logged and you can probably lower/disable the notification threshold.

Method 2 - Not recommended

I believe Windows has a way to disable WebDAV on the Laptops. This might invariably break something else, but it's worth looking into if your company doesn't use the service. (This will create a user complain train if it breaks something they use frequently, company related or not)

Security Concerns

If your company doesn't rely on WebDAV for anything and you block all inbound communication of WebDAV traffic you have minimal impact. There isn't anything really pressing about the WebDAV triggers that makes you go, OMG WE'RE DOOOOOMED, based on you initial analysis of it (I think you right to assume they are false positives). At this point it's baseline for you to look at, unless an attack has active knowledge of your directory structure, trying random WebDAV request will be pretty obvious even among the false positives.

In short, your pre warning will be hindered slightly, if you get accustomed to seeing tons of false positives.


Is there a way to make changes to a virtual machine, test it out, and automatically make same changes to normal machine?

Typically you script the making of changes (how you do this depends on what you're changing) run the script against the VM, test, and if happy run the same script against the real machine.


Is storing CVV compliant with PCI standards?

Storing CVV is not allowed:

There are a few things to consider:

You assume booking.com is storing CVV
You're assuming a CVV is needed to process a transaction.

On 1) - there can be no way to confirm whether booking.com, Expedia are storing unless you work there. They would have to answer to a QSA. Now, as far as the CVV that is stored, that is CVV2 information, it's used for CNP transactions. What I can see a company doing, is perhaps making a cryptographic hash, storing the hash and making a comparison.

On 2) - again, CVV is just an additional mechanism meant to prevent fraud. It it not really needed to process a transaction.

Once a process is authorized, some credit card companies give merchants other identifiers to use for future validation. This can be read/explained via Visa's "Merchant's Best Practice for Recurring Transactions."

Had I to guess how it works:

Consumer --> (CC + CVV2) --> Merchant
Merchant --> process this --> VISA
VISA --> all is good to go btw here is a summary [additional code] for future reference --> VISA
Merchant --> stores additional code for future reference
Consumer (months later) --> "I want to buy this" --> Merchant
Merchant --> we have data from you, and also from Visa
Merchant --> processed thank you --> Consumer

My best guess on a limited amount of reading, and or caffeine.


No the exact code you have posted is not vulnerable to XSS.

Now if you are writing first_name to the page anywhere it could be a reflected XSS vulnerability or maybe a DOM based XSS vulnerability.  But the tiny piece code you have posted is not a vulnerability


Does calling with wireless phone have enough security?

It depends on what you mean by "wireless phone at home":

GSM phone - then yes, all transmission between your phone and GSM station is encrypted
DECT phone - then partially: all wireless transmission between the phone and its base station is encrypted, however neighbours can plug into your analogue, unencrypted phone cable
cheap no-name wireless phone - it depends on what technology have been used, but still your neighbours can plug to your analogue, unencrypted phone cable

You can avoid plugging to an analogue phone cable by using ISDN phone (where available), or VoiP.


Is it possible for Apple or any other company to create fully encrypted smartphone?

It'd be a piece of cake.  All you need to do is manage the safety of the secret (i.e. the handling of the PIN) in firmware, and make it so you can't update the firmware anymore.  The ability to prevent a device from accepting additional firmware uploads has been around for decades, usually under a name like a "fuse bit."

Of course, the consequences of this is that Apple becomes incapable of updating the firmware if anything goes wrong.  Naturally this is unpopular, so companies elect to not do it.

There's also the exotic solution of a Key Ceremony.  It's a fascinating topic to read about, but the long story short is that it ends up splitting the root key into several dozen pieces, giving each person a different piece.  If each piece of software had to be signed by such a key, it would be virtually impossible to get all the keys together for a second signing.


How can I avoid buffer overflows when programming an Android app?

Android is similar to other operating systems, if you code in Java then you shouldn't be worried about buffer overflows but if your code contains native code e.g. C++ or C, then you should avoid any possible buffer overflow vulnerabiliy. The instructions to avoid BOF in Linux can apply for android too, so you can use them.

http://www.cprogramming.com/tutorial/secure.html


Is there a tool to test whether a server supports any cipher suite?

Testssl.sh can detect bad ciphers and a lot of other things regarding SSL security.

Edit:

Even testssl.sh depends on OpenSSL for the ciphers it tests. It ships with its own OpenSSL libary that has many depracted ciphers enabled. You should use testssl.sh with that OpenSSL library, not with your system's library.

However, even testssl's OpenSSL library does not support all existing ciphers in the world. According to Dirk Wetter, testssl.sh's developer:

  There are cipher suite which are not scanned -- as there's a wealth of ciphers around and
  only a part is being used in the internet.

   Bad ones: nope, everything should be included with the accompanied openssl binary.

  New ones in practical use: a few which are being used by Google so far (new chacha/poly
  ciphers and post quantum ciphers).

  We're aiming at testing every single cipher per bash sockets in the next release.


Received letter from attorney stating they found a pirated copy of software on my computer based on my MAC address

I am being threatened with a lawsuit...  Can the company prove that it
  was me using the pirated version?

That is a legal question which no one here can answer (and you'd be best getting professional legal help with).  However, several aspects of your question do touch on interesting aspects of security-related license DRM issues, so let's talk about those a bit.

  Can a MAC address lead a company to the specific user?

In general, no.  However, a MAC address can be used as a compelling indicator as to which computer something happened on.  That's the reason that most "licensing software" used to use MAC addresses to "identify" the computer they were installed upon.  Because MAC addresses are unique-ish, and because altering them is not brain-dead easy (and used to be quite hard), it's often treated as an identifier of the system that something happened on.

  They have my phone number and an old email address for me. The
  information they sent me is showing a MAC address and the specific
  number of times the pirated software was used and the dates it was
  used.

It is very likely that files generated with this software include these things as metadata - again, primitive DRM practices do love the MAC address.  If the company found files you generated, which had grabbed your email address (did you register a support account?) and included the times those files were operated on, then they'd have what they needed to gin up a letter for you.

But the lesson here is, every file you generate with software may include all sorts of metadata you didn't expect to be in there.  Caveat emptor.


How long it takes to receive CVE-ID from cve.mitre.org?

It seems for most cases cve assigned automatically in next 24 hours. When they have technical issues they post them at https://cve.mitre.org/news/. I had an issue due to badly configured filters in my email. I was able to receive letters from CVE-Request@mitre.org, but not from other *@mitre.org senders. Keep in mind that some mailboxes like gmail can block some emails entirely (so they don't even appear in spam folder).


Is VirtualBox safe and is it possible its spying on the user?

Both VirtualBox and VMWare are safe, reputable hypervisors. A website that looks "old" is not an indicator of malice, and sometimes the most reputable websites look very old indeed. VMWare has more closed source components than VirtualBox, which can make it less trustworthy as a result of a closed design. Neither of them are going to actively spy on you, though. If you want to really be sure, verify their PGP signatures, if they have them. They are likely provided on their download page.
You should know, however, that your operating system may end up writing sensitive information in RAM to swap space on your disk, so using a virtual machine for anonymity is not always the best idea if you don't know what you're doing. Furthermore, any virtual machine software can contain bugs that could allow the guest to break out. As long as you keep them up to date, along with the rest of your operating system and the guest running in the VM, the chances of that are minimal.


Cheap and efficient strategy to protect against professional attack?

With your disconnected computer, you are describing an Air Gap.  A quote at a recent security conference:  "An air gap just means higher latency in the network"

You are right that it is very difficult to be perfectly secure. Instead of trying to be perfect, try to improve.  Do a self-assessment and calculate what your biggest risks are and then use technical and non-technical solutions to reduce those risks.  Then, repeat.  An air gap might indeed be one of the technical solutions.

You don't necessarily have to be better, technically, than the state-sponsored attackers.  They are limited by the same technological realities that you are.  You do, however, have to invest resources (technical, human, financial) in a defense-in-depth strategy that takes into consideration possible bypasses employed by state sponsored attackers.  There are smarter people than you and me working on defensive strategies, so your resources should be devoted to following the experts and letting them help you reduce risk.


There are no 'scanners' yet, but you might be able to enrich existing code scanners with new rules for the HTML5. OWASP HTML5 Security Cheatsheet is a good resource you might use to compile such rules, for example it lists insecure CORS headers configuration, but it also touches other HTML5 subjects like insecure WebSockets configuration. You can also add e.g. new XSS vectors using HTML5 features from http://html5sec.org/ - there's a text-only version of these payloads on GitHub.


oidc: do I have to verify the id token if I only use the access token?

Not an expert but from my understanding so far..

You need to validate both access and ID tokens to ensure that the claims in them are trustworthy. You can validate in any of these ways:

Use symmetric key. In this case, the key should never reach the browser, and we need to be careful to only share with trusted entities.
Use asymmetric key. In this case we can share the public key freely with any client, including the browser so they can verify the key locally. The key can be part of the front-end code of your app or simply be returned by an endpoint from your application.
Use endpoint. OpenID Connect provides the access_token/introspect endpoint that let's us know if the access key is active. There is no standardized endpoint for the id token.

Now, in terms of validating the ID token, I think you shouldn't even request for it if you don't need it. That will make it also apparent if you need it or not. In practice, if you don't show any of the authenticated user's info in the interface (e.g. email, username, profile photo), you probably don't need it.


What are the OpenSSL standard Diffie Hellmann parameters (primes)?

The behaviour of OpenSSL, as a library, is documented in the man page for SSL_CTX_set_tmp_dh_callback(). Basically, the library itself contains no pre-generated DH parameters and will refuse to do any "DHE" handshake until such parameters have been provided. The caller (the application which uses OpenSSL for running an SSL server) may provide DH parameters preemptively (either "attached" to the structure containing the server's certificate, or with an explicit SSL_CTX_set_tp_dh() call), or through a callback function which will be invoked for each relevant handshake. The callback method gives the application the opportunity to modulate the DH parameters, in particular their size, based on the cipher suite and other parameters currently being negotiated (this was important for proper support of the old "export" cipher suites, but is much less relevant nowadays).

OpenSSL, as a piece of C code, also comes with command-line applications. E.g. you can run a SSL server with openssl s_server. Inspection of the apps/s_server.c source file shows that, unless overridden with explicit DH parameters (the -dhparam option, or appended in the server's certificate file), default parameters are used, with a 512-bit modulus (!). The provenance of this modulus is unspecified; but it cannot be considered to be really strong since a 530-bit discrete logarithm has been solved at least once.

Note that the apps/ directory also contains files named dh512.pem, dh1024.pem, dh2048.pem and dh4096.pem, which are DH parameters of 512, 1024, 2048 and 4096 bits, respectively. These apparently come from SKIP, an old protocol for IPsec-related key management, for which I found an old draft, which indeed contains the 1024-bit and 2048-bit modulus that OpenSSL source code contains as the dh1024.pem and dh2048.pem files. Interestingly (or not), the 512-bit modulus used by apps/s_server.c is NOT the same as the one in dh512.pem.

Since the parameters are caller-provided, let's see what happens in mod_ssl, the usual SSL engine for Apache. Let's make the story short: the modulus and generator are hardcoded; they are in the source code, in modules/ssl/ssl_engine_dh.c. There is a 512-bit modulus, and a 1024-bit modulus. The 512-bit modulus will be used if the server's public key has length 512 bits; the 1024-bit modulus will be used in every other case. So, in practice, it is always the 1024-bit modulus. The source code makes no mention as to how these parameters were generated; they are different from the ones which come with OpenSSL's source code. Apparently the whole World uses that 1024-bit modulus of unknown provenance (at least, the half of the World which relies on Apache+mod_ssl).

We may note that future versions of Apache, starting with the development version 2.5.0-dev as of 2013/09/29, will switch to hardcoded DH parameters of 2048, 3072 and 4096 bits, copied from RFC 3526. These DH parameters are supposed to be efficient (e.g. they use g = 2 as generator, and their 64 most significant and least significant bits are all ones, which may help in some implementations of Montgomery multiplication) and to be "obviously safe". Using DH parameters of more than 1024 bits is known to break poor SSL client implementations, in particular the one which comes with Java up to (and including) Java 7 (Java's SSL implementation is generally fine, but for DHE support it has a 1024-bit limit, which is kinda stupid since Java has a BigInteger class which is completely up to the task of DHing at larger sizes).

One must say that generating DH parameters needs not be that slow. OpenSSL insists on creating so-called "safe primes", where the "safe" is more marketing than science. A "safe prime" is a prime p such that (p-1)/2 is also a prime. This allows the use of any integer in the 2..p-2 range to be used as generator g, in particular g = 2, which yields a slight performance advantage. On the other hand, producing a safe prime is challenging: roughly speaking, when dealing with 1024-bit integers, only 1/1000th of them are prime, and only 1/1000th of these primes are "safe primes", hence a search loop which tries a million potential values.

Cryptographically speaking, one could also use as DH parameters the same kind of parameters used by DSA: p is prime such that p-1 is a multiple of a much smaller prime q, and g is an integer of order q. These can be generated in much less than 1 second, and will be fine for DH.


Is there any risk in placing a scan of a diploma online?

Not particularly.

The diploma itself isn't supposed to be a secure document, and is given to people to post on walls, not to present as verification of a degree.  A quick google image search reveals that many, many people have posted copies of their diploma's on the internet, so it's not like this would be a rare commodity.  Degree verification is done directly through the college/university, not through diplomas.

As long as you're comfortable revealing personal details of your life to everyone, I see no reason not to post a diploma.  Keep in mind that posting personal details about yourself makes you a bit more vulnerable to Con-men who can try to convince you to trust them based on this.  i.e. casually mentioning they went to the same school and got the same degree as you just a few years before/after you did.


Sending one type of network traffic over another protocol is called network tunneling or covert channeling. This is quite easy to do, and with some experience, you can send plaintext data over port 443 (to make it appear encrypted to the untrained eye) or send IM messaging traffic over port 80...the opportunities are endless.

The method of sending data over a covert channel is not encrypting the data, but avoiding detection that the data is being sent in the first place.

Here are some resources for you to read up on covert channeling as well as a couple of programs that can help you do this.

Resources

SANS Covert Channels article: Really awesome and contains lots of detailed info:
http://www.sans.org/reading-room/whitepapers/detection/covert-channels-33413
InfoSec Institute article: Some hands on examples using Kali Linux:
http://resources.infosecinstitute.com/creating-covert-channels/

Tools

6 packet crafting tools from sectools.org:
http://sectools.org/tag/packet-crafters/


If a company were to actually patch all their systems, then Metasploit would have very little to offer in that environment.  However, it's extremely common for companies not to patch all of their systems for any of a number of reasons:

Bad inventory management -- some companies don't even know all the systems they have
3rd party software that's only certified for old software
A belief that patching leads to instability/crashes/unacceptable downtime
Understaffed or underskilled IT department
Human error
Mistaken beliefs about security ("We have a firewall, why do we need to patch?")

There's probably other reasons I'm forgetting right now.  Even before the availability of Metasploit, there's resources like Exploit-DB that list exploits and vulnerabilities.  Companies didn't patch then either.

Look at all the other questions tagged patching for more insight into how patching is not a trivial problem.


How about PFsense on a PCEngines Alix or APU router? Wifi won't be more secure, as it's the protocol, but pfsense can monitor your network I believe. This is on my list as well, just haven't found the time to do this.

http://www.pcengines.ch/order1.php?c=2


Why it does not matter whether you type HEX or ASCII as WEP WiFi password?

According to Wikipedia's page on WEP:

  A 64-bit WEP key is usually entered as a string of 10 hexadecimal (base 16) characters (0-9 and A-F). Each character represents four bits, 10 digits of four bits each gives 40 bits; adding the 24-bit IV produces the complete 64-bit WEP key. Most devices also allow the user to enter the key as five ASCII characters, each of which is turned into eight bits using the character's byte value in ASCII; however, this restricts each byte to be a printable ASCII character, which is only a small fraction of possible byte values, greatly reducing the space of possible keys.

So in hex mode, 0 is 0, but in ASCII mode 0 is 48. Similarly, in hex mode F and f are both 15 (they're the same number), but in ASCII mode they're 70 and 102 respectively (different characters). You actually can convert the hex values to ASCII, but you probably won't get printable characters.


Is it advisable to tie different capabilities to different session tokens?

I have come across similar approach in complex applications which are microservice based. If different teams handle these services, having different session ID's tied to different capabilities can be a way forward. However it is not an elegant solution. The ideal approach should be to use the session for identification. The access control to a particular functionality can however be handled at the server side as a part of your authorization logic.

When a request comes in for making transfers have a server side logic to check for the following.

Whether the user is authorized to perform transactions?
Whether they have a session ID which was issued <12 hours ago?


How should a network be configured for an IDS server?

You need to select your IDS location based on what you need. If you have a very small network with one switch, then this can be easy, but for a larger network estate there are a few options:

Gateway: have your IDS connected to your perimeter router/firewall so that you can monitor everything coming in and out of your network. This requires a huuuuge amount of tuning, as there is so much automated stuff trying to gain access.
Crown Jewels: locate your IDS on the subnet your key assets are on, this way you only see traffic that has got this far - so tuning out false positives should be much simpler. The downside is that you don't see anything else on the network.
Agents: you can give routers and switches, or even desktops, an agent which feeds into an IDS (often via syslog or other common mechanism) and you can base this on your specific requirements.

Remember the biggest problem with any IDS is keeping it tuned to reject as many false positives as you can while alerting on suspicious traffic - and then having a team respond and assess those alerts. The amount of traffic even on a medium sized network can be incredibly hard to sift through...


AH can be easily inspected by firewalls. ESP with NULL is similar but (AFAIK) the firewall doesn't know that it's the NULL cipher and has no easy way to tell after a connection has been established.

So if you want authentication only then that's a plus for AH.


As of today (April 5th, 2016) The project was shut down due to lack of contribution, and there is no plan for it to return.

  As of today, a decision has been made to shut down the Open Sourced Vulnerability Database (OSVDB), and will not return. We are not looking for anyone to offer assistance at this point, and it will not be resurrected in its previous form.


Server encryption, client decryption, without the client having the ability to encrypt?

You are probably mistaking encrypting for signing!
Being able to decrypt something does not imply that the encrypted data comes from a trusted source, which is what you likely want from a licensing software.
Rather, what you should do is to sign the license key, and allow the client to verify the license. This can be done using public-key cryptography. Your server would contain the private key, with the ability to sign data, and your clients would contain the public key, with the ability to verify a signature.
However...
... it should be noted that what you are trying to do is a DRM scheme, and theses schemes are impossible to do with any reasonable guarantee of security, at least if all the "interesting" bits happening on the client.
Your program, in essence, looks like this:
if(license.IsValid())
{
    startTheCoolStuff();
}
else
{
    showLicenseError();
}

You can make this more complicated and throw some obfuscation at it, but it won't change the fundamental nature of the approach. And an attacker, eager to circumvent your licensing, will find a way to execute startTheCoolStuff() without a valid license.


Protecting my high-value passwords against offline attacks

I've used both KeePass and LastPass, and I'll share some of the things I found helpful when deciding to use a web-based password manager.

There's a paper by some folks at Berkeley who analyzed various online password managers. This link points you to that paper. LastPass fixed the bookmarklet issue.

For threat #1: A strong master password (read: long and random) should not be crackable, assuming that the password manager developers did their job properly. I have to rely on the crypto pros to make that evaluation.

Now that LastPass has been hacked I guess I'll get to find out if they did.

For threat #2: Phishing threats are very real and can defeat 2FA (see this Brian Krebs piece). I don't see how LastPass avoids the kind of attack Krebs describes. He recommends banking on a live CD to avoid system compromise.

For threat #3: don't re-use passwords.

If your major concern is that someone might get your encrypted password database, then you're somewhat more secure with KeePass or other local solution than with LastPass. However, that's not total protection. If your system gets compromised, or you get phished, local storage doesn't protect you.

The threat I think you're overlooking is this one: do they even need your password to get into your bank, etc? Matt Honan wrote about this.

If there is an easier way into your bank account than brute-forcing your database password, then that's the threat you need to worry about. I hope the links I provided were helpful.


Smart cards and the behaviour of the browser. Is the PIN cached?

Assuming you use windows.

The PIN is cached to avoid having to re-enter it. The certificate is on the smart card and cannot be cached as the pin is used to unlock it.
I don't think Chrome can cache the pin as it's handled by the credential providers and not the application itself.

Relevant info from https://docs.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-architecture#pin-caching:

  PIN caching

  The PIN cache protects the user from entering a PIN every time the
  smart card is unauthenticated. After a smart card is authenticated, it
  will not differentiate among host-side applications—any application
  can access private data on the smart card.

  To mitigate this, the smart card enters an exclusive state when an
  application authenticates to the smart card. However, this means that
  other applications cannot communicate with the smart card and will be
  blocked. Therefore, such exclusive connections are minimized. The
  issue is that a protocol (such as the Kerberos protocol) requires
  multiple signing operations. Therefore, the protocol requires
  exclusive access to the smart card over an extended period, or it
  require multiple authentication operations. This is where the PIN
  cache is used to minimize exclusive use of the smart card without
  forcing the user to enter a PIN multiple times.

  The following example illustrates how this works. In this scenario,
  there are two applications: Outlook and Internet Explorer. The
  applications use smart cards for different purposes.

  The user starts Outlook and tries to send a signed e-mail. The private key is on the smart card.
  Outlook prompts the user for the smart card PIN. The user enters the correct PIN.
  E-mail data is sent to the smart card for the signature operation. The Outlook client formats the response and sends the e-mail.
  The user opens Internet Explorer and tries to access a protected site that requires Transport Layer Security (TLS) authentication for
  the client.
  Internet Explorer prompts the user for the smart card PIN. The user enters the correct PIN.
  The TLS-related private key operation occurs on the smart card, and the user is authenticated and signed in.
  The user returns to Outlook to send another signed e-mail. This time, the user is not prompted for a PIN because the PIN is cached
  from the previous operation. Similarly, if the user uses Internet
  Explorer again for another operation, Internet Explorer will not
  prompt the user for a PIN.

  The Base CSP internally maintains a per-process cache of the PIN. The
  PIN is encrypted and stored in memory. The functions that are used to
  secure the PIN are RtlEncryptMemory, RtlDecryptMemory, and
  RtlSecureZeroMemory, which will empty buffers that contained the PIN.


I am having difficulty maintaining a wpa handshake (4 way handshake) airodump-ng

You could sniff packet using wireshark and check if your NIC is sending those packets. Anyway, I would recommend not to use aireplay with the second 0, maybe someone is trying to start the 4-way handshake and you send him a deauth packet (it is not very likely, but it could happens).


Diagram of personal information security vulnerability?

I am not aware of a diagram set but there is veris:
veris framework

It translates the "Who did what to whom using which attack vector" in a structured JSON Format. It uses a 4 dimensional model for threats to describe any incident.

Actors
Actions
Assets
Attributes

So the example model from above would be slightly different, you can model every incident with those 4 dimensions and then link them together via the asset used and its attributes.

I personally like the structure when establishing kill chains for apt attacks.

Another option would be the attack tree model from Bruce Schneier Attack Tree Model

There you go backwards through the steps for a given attack, starting by the affected asset and then model every step the attacker has to take to gain access to the asset. This would model the above given scenario from the bank account backwards and create a path for the attacker. Then you can assign probabilites and cost to every node to model the most likely way any attacker would go.

A more sophisticated approach ist the SANS Threat modeling approach
This creates a campaign out of the attack tree an then describes every step as an scenario.


Is it possible to tell if an email went through a proxy type service where the email might be monitored?

Yes.

This isn’t anything new though.

E-Mails may get forwarded several times between MTAs, whereas every MTA can (and must) see (at least) the headers of the message.

That is one of the reasons for deploying (and using) end to end encryption: end to end encrypted email bodies cannot be read in transit by forwarding MTAs.

The padlock that google shows only indicates that the transit between the last MTA outside of google and google has been encrypted; this does not mean however that the transit MTAs not read (and possibly even modify) the email.

You can witness this behavior with several free web mail providers who append an advertising signature to emails even if they are sent via a mail client. That is possible because the MTA has access to the whole of the message when processing it. A malicious MTA in this chain (you might call it a proxy from a functional point of view if it is the first hop of outbound and last hop of inbound mails) can easily copy all emails.

That being said, one would have to have control over an MTA within the delivery chain of all emails, but there are several ways how to do that.

Also: there is no way to tell wether an email has been copied in-transit while being processed by an MTA, other than the other answer is suggesting.


What are those nul bytes doing in Certificate Subject CN?

This is a badly encoded Common Name. The Common Name, like many elements of a Distinguished Name, can be encoded in several ways, including UTF8String (that's UTF-8) and BMPString. The latter is more or less the same as UTF-16, with two bytes per character (except surrogates, which I won't talk about here). Apparently, someone encoded *.mcafee.com in big-endian UTF-16, but it was decoded as if it was UTF-8 (or ASCII), leading to the spurious null bytes. It was probably improperly tagged in the certificate.


A hash is a one-way digest function. It takes a number of input bytes and computes a fixed-length value from it. If you compute the same hash again, you get the same result. Generally the numeric value of the length of the input is not considered, as the data is inherently changed if you change the length.

Hashes cannot be decrypted. They are lossy compression functions by nature and in most cases you cannot recover the full original data from them (this may not be the case for non-cryptographic indexing hash functions and small input values).

There are three main types of hash function: those used for indexing, integrity, and cryptography.

An indexing hash (e.g. MurmurHash or Java's hashCode) can be used to divide equal or very similar values into groups for improved performance in collection operations. For example, by precomputing a hash of each object and keeping the internal array for a collection sorted by the objects' hashes, lookups can be performed in worst case O(log n) time rather than O(n) using a binary search. The general requirements for indexing hashes are as follows:

Extremely high performance
Generally specialised to certain input data types (e.g. ASCII strings or pointers)
In some cases, designed to produce output values which represent the magnitude of the input value. For example, in string searching, you might choose to convert the first four characters to their ASCII integer values and interpret those together as a 32-bit integer, since sorting that integer also pre-sorts the list alphabetically.

An integrity hash (e.g. CRC32), sometimes called a "redundancy hash", has the properties necessary to provide a fairly good indication of accidental corruption of a file. These hashes will generally produce a different hash when a bit is changed, but will not withstand someone purposefully trying to generate a collision. For example, the strings "Maria has nine red beds." and "Steven has fifteen white tables." are different but generate the same CRC32 hash of 0ECB65F5. The general requirements for integrity hashes are as follows:

Have a high statistical likelihood of producing a different value when an input bit is changed
Works with any type of input data (universal)
Very high performance

These two hash function types generally make little effort to prevent someone from learning about the input data or finding collisions. This is why they are considered non-cryptographic.

A cryptographic hash such as MD5, SHA1, SHA256, or Keccak, has many more requirements. These hashes are designed to be highly resistant against attempts to discover any information about the original input data, or collisions in the hash function. The general requirements for a cryptographic hash function are as follows:

It should be very difficult to determine any information about the input value from the output value, even if an attacker can select parts of the input.
Each output bit changes with a probability of roughly 50% when any one bit in the input changes.
Resistance to first order preimage attacks, i.e. if someone gives you a hash value y, it is very difficult to find some value x such that h(x) = y. Or, put more simply, it is computationally infeasible to find the input value that produced a particular output value.
Resistance to second order preimage attacks, i.e. for any given input a it is very difficult to find another value b such that h(a) = h(b). Or, put more simply, it is hard to find a collision for a given plaintext.
General collision resistance, i.e. it is hard to find any two values a and b such that h(a) = h(b) even if the attacker selects both a and b.
Works with any type of input data (universal)
High performance

As you noted, it turns out that these functions are quite useful for obscuring passwords and turning passwords into cryptographic keys, although their main purpose is not for password storage or key derivation at all. In fact, it turns out that using a plain hash function for either of these purposes can be quite insecure. You can read about the arms race between attackers and defenders of passwords here, and more about good practice here.

When a hash function or password storage function is used, the verification is not done by decrypting anything. Instead, the password given by a user is hashed in the same way and the resulting hash is compared against the one in the database. If the password is correct then the hash will be the same, otherwise the hashes will not be equal and the server can reject the login attempt. This is generally flawed with basic hashes like SHA256, though, so I suggest reading the two links I posted above to better understand why and what good practice options you have.


It is very possible to identify the SIM based on the IMEI if the phone is powered on, and on the network. The problem is that you most likely do not have access to this information unless you work for the carrier, and typically these guys don't care about your stolen phone enough to disclose this information. Sorry for your loss and good luck.


Google Chrome is redirecting before visiting a shopping website

Most probably it's a malicious extension
Sometimes when you install software, the installer installs extensions to your browsers along with it. If you have recently installed a software from an untrusted site, it could have installed this extension on your browser.

You can try the following things:

Visit Amazon from some other browser to see if it's only a chrome problem
Check the extensions on all the affected browsers to see if there is any extension that you don't remember adding
If that doesn't solve your problem then go the advanced browser settings and check for any funny business


Is it okay to log sql queries for debugging

You are talking around the idea of "data classification" without actually talking about it.
The data in your database has a certain level of data classification, whether you formally assign a classification or not. You secure and control this information based on its sensitivity and classification (e.g. passwords, personal data, company-sensitive data, etc.).
If you log query data, then those logs now have this data and should be secured and controlled in the same way as the database.
To not secure and control this data in the same way in line with the security and controls in the database that supports the data classification, then, yes, you are inappropriately exposing this data.
So, yes, it is ok to run debug logs of queries, as long as you secure and control it in line with the protections the data requires.


Creating a "key server" (HIPAA compliance with AWS)

The HIPAA requirements not nearly strong enough.   In short it states that you must encrypt medical records at rest and you cannot use a broken primitive,  which is obvious.  Whoever audits your system probably like to see AES.  This is trivial to support, and an Amazon RDS MySQL instance already supports this out of the box with the aes_encrypt() and aes_decrypt() functions.

Where HIPAA and PCI-DSS fall short is that they don't state what mode of operation should be used.   In fact MySQL's aes_encrypt() uses ECB mode,  which is horrific.  Further more, there are problems with enforcing security when using encryption at this layer.  aes_encrypt() is easy to break by configuring mysql to log all queries.  The AES key must be embedded in your application so if it is compromised, the attacker could read the value out of a configuration file and access the records.  This is two points of failure that can be avoided by encrypting the data within your application and then transmitting cipher text to the database.    But HIPAA doesn't care about this problem.  HIPAA's other requirements,  such as requiring a CISSP to analyze your application is more important.

So no one needs to spoon feed you this masturbatory security feature.  I urge you to implement a secure system,  but HIPAA wasn't designed well enough to care.


Well ... besides using a security-token (e.g. YubiKey) as the 2nd factor:

Google does offer an advanced-Security Program for activists, journalists, etc which would fit perfectly with your needs.
https://landing.google.com/advancedprotection/

But you do need to buy two hardware-security keys, because one is always needed when logging in at another location.
And the other one if you ever happen to lose your first one. Maybe because without any pre-configured security-token you might not be able to change any settings etc.?

I would buy at least two. YubiCo does offer several options, where the cheapest is already everything you need for U2F.
Set up both and place your 1st key on your (actual) keychain and your 2nd one in a safe at a 3rd-party (your grandma's house or your bank).


how to protect from Network scanner on android?

This kind of attack are very moving in form, tools, and manners. (one day it's vlan, that offer some backdoors, another day, there is SIP... or some .mp3 plugins...)

Depending on what's new security failure where discovered...

But Android community is very quick to build patchs and correction for dangerous sercurity failures.

So the right answer is (as I think):

Any scanner, depending on which failure have to be exploited
Don't try to do that if you're not a network security expert;-)
Keep your system up to date!

And if you're in doubt, ask a friend to trace network activities and maybe to inspect your system.

(Don't buy expensive anti-virus or other anti-spy software, as they are as obscure as malwares you try to stay away.)


Yes, if you see HTTPS:// in your browser window, haven't accepted any certificate warnings and you are visiting trustworthy website like a bank, your data back and forth would remain private.

If you HTTPS session were being attacked you should get a certificate warning. This might happen a) due to a fake certificate from an attacker, or b) sometimes just due to a "captive portal" trying to proxy every https connection (still not cool).

This assuming that

You didn't previously accept an SSL warning.
The attacker doesn't have their own custom Certificate Authority root cert installed and trusted by your browser.
The HTTPS site isn't including any mixed-content (content from HTTP sites included by HTTPS page).
Your computer doesn't have other programs that are calling over the network in plain-text that can be compromise your workstation. Example, browse to a plaintext site with IE, and an attacker may insert a browser exploit into another connection to compromise your computer. (super rare for public wifi)

Personally, I do banking from coffeeshop wireless, confident that may data is protected. It is pretty similar to using banking applications on mobile phones.


One needs to know your snort.conf and other Snort settings to answer this. Still I shall try to answer with whatever limited information you have provided.

In all probability, the threshold settings for the portscan preprecessor (called as sfportscan if I remember correctly) are set to some higher (default) value in your snort.conf, and the portscan you did could not cross those threshold values.
Another reason could be that your $HOME_NET variable is defined in such a way that the IP you are scanning is not in your HOME_NET and thus Snort doesn't care about scans on it. There could be other reasons too, such as the IP you are using to scan as well as the target IP, both are part of your HOME_NET, and thus again Snort does not care about a HOME_NET-to-HOME_NET scan.


How to verify SSL cerficate If restored session after session broken?

That should never happen.  User is requesting your site via https://example.com.  The user's browser will expect the server to provide a cert with hostname of example.com.  Hacker can not MITM that as hacker will not have the example.com private key to sign a message and authenticate as example.com.  User's browser will report an severe warning.  If hacker supplies a cert and signature for hostname hackercert.com the browser will warning the hostname is incorrect.  If hacker supplies no cert the browser will report server is not available.  If hacker suppliers proper cert and invalid signature browser will report there is a problem with the cert.

So the scenario you describe can't happen which is a good thing because if the hacker is MITM you can't do anything the hacker doesn't want you to do.  The hacker is between the client and you.  So even if there was a "reverify this cert because the other one is bad" command why would the hacker ever let the client see it?

So my guess is either you have a misunderstanding of TLS or I have a misunderstanding of your question.


Does altering the routing table to my hub defeat the purpose of a VPN?

The VPN will take the route that finds valid at the time when its connection initializes, so it will connect with regard to the current routing settings.

If you alter routes after the VPN is connected, depending on various factors, the VPN may still work or disconnect. If it continues to work, the new routes (set by the scrip loaded after VPN is connected) will also function correctly.

So no, doing this does not defeat the purpose of the VPN.


How to prevent a docker container from being attached by multiple users?

If a user on a Docker Engine host has rights to execute docker commands (via either having sudo privileges, or membership of the docker group) there is no way (with the base Docker product) of restricting them from attaching to containers running on the host

Effectively providing docker access is the same as providing root on the host.

So to prevent it, the key is don't let other users have rights to run docker commands on that host.


Password cracking using Quantum Computers

Where a traditional brute force would take m^n computations, a quantum computer would use √(m^n) computations, using Grover's algorithm. Using a password that is twice as long, or using twice as many bits in symmetric encryption give adequate protection against quantum computers.
For asymmetric algorithms, this is different. Using Shor's algorithm, RSA completely falls apart on quantum computers. We would need post-quantum algorithms to have secure asymmetric encryption.
As you can see, quantum computers allow algorithms that wouldn't be possible on classical computers. This enables them to solve problems faster. Quantum computers are not faster classical computers, they are fundamentally different.


How to handle two sets of OpenID credentials providing the same information, on the same or different OpenID providers?

Your concern is justified, this behavior should not be allowed. Quoting myopenid help page:

  OpenID is a decentralized identity system. An OpenID identity is just a URL. All OpenID does is provide a way to prove that you own a URL (identity).

Any additional information associated to that URL is not [necessarily] trusted, unless the OpenID provider also happens to be authoritative to that information (for instance, Google is an OpenID provider and an e-mail provider, so when Google says "the owner of this [google] URL is also the owner of this GMail account" you can trust it). Even those sites that take additional steps to validate the users' e-mail addresses are still not authoritative to them, and the validation only proves that the user controlled the address at the moment of validation (i.e. the e-mail might have changed hands, if it's a corporate e-mail for instance, or the user might have registered with a shared e-mail, etc).

The proper behavior would be either:

Register two distinct accounts with the same e-mail address;
Deny the creation of the second account (if for any reason the e-mail address must be unique);
Offer to link/merge both accounts, requiring that the user authenticates again with the first account, thus proving s/he owns both URLs (the associated info being irrelevant).


Logging into remote server via SSH using VPN (Wireguard). Is it foolproof?

It is foolproof in the sense that someone can only gain access if they have your credentials, or if there is a vulnerability in Wireguard. But in the same sense, exposing an SSH server is foolproof.
The most attractive aspect of this setup is probably that Wireguard exposes a smaller attack surface than SSH.
Whether this is a good architecture depends on your exact goals and on your threat model. Whereas having to log in into through two separate systems (Wireguard and SSH) and reducing the attack surface can increase security, it could also decrease security aspects such as availability: there are now two critical systems instead of one, and misconfiguring any would deny you access. For the threat that credentials on your client system might be compromised, you've correctly analysed that adding Wireguard does not add security.
That an attacker would need to know a particular IP address should not be assumed to add any security (see: security by obscurity, Kerckhoffs's principle).


Can chipped cards without a stripe or with a blanked stripe be exploited by this attack?

I haven't seen the talk, but based on the description and their slides, I'm pretty sure that you're conflating two separate attacks.

  ... credit card thieves can rewrite the magnetic stripe code to make it appear like a chipless card again.

The magnetic track data on a credit card contains (among other information) a three-digit service code.  A service code that begins with a 2 or a 6 indicates that this is a chip card, which is how the terminal knows to tell you to insert the chip if you have one.  By changing that first digit to a 1 or a 5 (and appropriately altering the check digit), they can trick the terminal into thinking it's a chipless card and permitting the swipe.

This attack won't work under normal circumstances, because the entire swipe data is sent to the bank to verify.  Changing the service code will cause the data the bank gets to be wrong, and it'll reject the transaction "on the back end", as the article you linked to says:

  "If the data on the magnetic stripe is altered it might fool the terminal," said U.S. Payments Forum director Randy Vanderhoof. But on the back end, the system would "reject the transaction."

However, merchants have the capability to do "store and forward", aka "offline mode".  Slide 24 points out that EMV fails to "Prevent using modified Track 2 in offline mode", which is very true.  This happens when the POS is unable to actually connect to the card networks to get an authentication from the bank.  Rather than reject all transactions (lost business!) or require calling the bank to get a verbal auth code (lost time! customer confusion!), the business just decides to store all the transactions and forward them later, when things are back online.   Since there's no connectivity, there's no way to know whether the data is valid, if the card is over its limit, or any of the other usual safety checks.  The merchant accepts the risk of that in order to continue doing business.

Obviously, in this mode the altered track data won't be caught until it's too late, and the transaction fails to forward, bypassing EMV altogether.

  ... because of the way many retailers are upgrading their payment machines: They're not encrypting the transaction.

This is a separate issue, where the merchant's terminal transmits the card data to the POS in plaintext.  Even if the POS then immediately encrypts it (either for store-and-forward storage or to actively transmit), it was still in the clear over one leg of the network, which provides opportunity for compromise.  The section of the slides that starts on page 13 address one (of many) attacks on this: Networks shims.  If you can put your device or code between the terminal (POI) and the payment app that encrypts it, or between the (non-encrypting) app and the POS software, then you can read off the data as it goes by, undetectably.

The counter to this one is on page 41 and higher:  Point-to-point encryption (P2PE).  With P2PE, the device encrypts the data itself, using a pre-loaded key.  Now, no matter where you interject yourself into the process, you can't retrieve the card data, because it's encrypted all the way to the gateway/processor/card network.

This still doesn't protect you against skimmers (page 39) or attacks on the device's software (page 40 and earlier), but it reduces the attack surface.


What security advantages does Hashicorp Vault have over storing secrets (passwords, API keys) in environment variables?

Vault's promise is "secrets as a service". It supports static storage of secrets (think encrypted Redis/Memcached), pass-through encryption (give Vault plaintext, vault gives back ciphertext that you store in a database), and dynamic secret acquisition.

On the static secret side of things, data is encrypted in transit and at rest. Data can be stored in memory, on the file system, or in third-party tools like Etcd or Consul. This is great for application-level secrets. Vault supports online rotation of the underlying encryption key. If you have FIPS/HIPPA/PCI compliance requirements, Vault makes it easy to check off most of those boxes with the default configuration.

With the pass-through encryption (or "transit" as it's called internally), Vault acts as an encryption service, accepting plaintext data, encrypting it, and returning the ciphertext. I wrote about this process in much more detail on the HashiCorp blog, but the process is simple. This ciphertext is then managed by your application. When the application needs the plaintext back, it authenticates and authorized to Vault, provides Vault the ciphertext, and Vault returns the plaintext (again, if authorized). There are a ton of benefits here, but the biggest ones are: 1. You don't have to build a symmetric encryption service into your application; just make an API call, and 2. The encryption keys are stored in a completely separate and isolated service; if an attacker must compromise multiple systems. Additionally, Vault's transit backend supports this concept called "derived keys". This enables things like per-row encryption keys for data stored in a database, such that even if an attacker had a database dump and could brute force the first encryption key, that key would not decrypt the other rows in the database. Just like the static secret backend, the transit backend supports key rotation.

The dynamic secret backends, in my opinion, are where Vault truly separates itself from other or home-grown solutions. Vault can connect to and dynamically generate credentials from things like databases, cloud credentials, CA certificates, manage SSH access, and more. Unlike traditional credentials, these credentials have a lease associated with them, akin to something like DNS or DHCP. When an application is given a credential, it's also given a "lease" or lifetime of that credential. Over time, the application (or a service) must communicate with Vault that it's still using that credential or Vault will revoke it. This helps eliminate secret sprawl while still providing a programatic way to access credentials. Since this is programatic, each instance of the application (or python script in your example) receives a different secret. You can easily revoke a single application's credentials without affecting the entire system.

Here are some use cases that might help you get buy-in internally:

Use Vault's GitHub authentication to authenticate your developers and operators. GitHub team membership is mapped to policy in Vault. Anyone in the ops team gets SSH access to prod, and anyone in the dev team gets the ability to generate dynamic AWS account credentials in the staging environment for testing.
Use Vault's AppRole authentication to have applications authenticate to Vault and retrieve a token. From there, the application's policy allows it to retrieve startup data, such as a database credential. If the app crashes, the database credential is automatically revoked when the lease expires.
You've detected a data leak. You can immediately revoke all affected credentials. This is called a "break glass" procedure.

As an additional note, you can use a tool like Consul Template to pull values from Vault into a template that your application can then consume. Your application does not need to be "Vault aware".

And finally, probably not related to your problem given the post, but it's worth pointing out that Vault also solves the "no one person has complete access to the system" challenge that most organizations face. By using Shamir's Secret Sharing algorithm, the process for bringing a Vault server online is very similar to unlocking a traditional bank Vault - multiple people must enter their key simultaneously to unlock. You can also read more about Vault's security model.

For videos that have demos and stuff, check out:

https://www.youtube.com/watch?v=8kafXiaCdRw
https://www.youtube.com/watch?v=-Re7J-3EDNY
https://www.youtube.com/watch?v=iMI9-6jcYiY


Send a unique string of text, a.k.a. a token (cryptographically secure, randomly generated), to the user via some other band besides e-mail, such as SMS or even snail mail. They can change their password in your app only if they input that token in a Web form on your site.

Or use physical devices, like SmartCards, that all users must have in order to use your app.


What is the purpose of SSL Certificate Authority (CA)?

What OP are asking, is "What prevents dishonestcompany.com from buying a SSL certificate for dishonestcompany.com and then running a fake webshop from there, collecting card details."

The thing is that this is not something SSL certificates are designed to prevent. SSL certificates are designed to prevent someone impersonating another site.

Certificates also provide a ID card for the website in question, so if the organization in question have purchased a higher grade certificate, or even a EV certificate, the owner of the website can be identified, and prosecuted in case of any fraud.

You can see certificates like a ID card in real life. As with all ID cards, you cannot just accept everyone having a ID card, then you lack a "authorization" step. This is same with for example signed software. What you need to do, is to verify, that the verified identity is the identity you wish to talk to.

You can see this as:
Real Identity -- Claimed Identitiy -- Wanted Identity.

A CA provides a link between Real Identity and Claimed Identity. But for everything to work, you also need to make sure to verify the Claimed Identity matches the Wanted Identity.
Eg, if you go to "dishonestcompany.com" to do your internet banking when you intented to go to "internetbank.com", then SSL certificates will not prevent you from felling into the trap.

Without CA's however, theres no link between Real Identity and Claimed identity, so even if you verify that Claimed Identity is identical to Wanted Identity, you can fall in the trap if you are victim of a MITM attack.

The browser verifies that the certificate matches the hostname you typed in, but YOU as a human, need to verify that the typed hostname is really the one you intended to visit!

In laymans terms, lets say you are Barack Obama, and want to let in Joe Biden into the white house.

What CA's in this case is, the one who issues me a ID card with the name "Sebastian Nielsen" on it.
BUT:
Lets say I show my ID card "Sebastian Nielsen" to you, and you let me in because I own a ID card. The ID card is no indication that im thrustworthy or wont do any harm. Its just a identity card. What you need to verify, is that the name on the ID card matches the name you want to talk to. This is called "authorization", eg checking that the identity is authorized to access the White House. Eg, you need to check that the name is on the list of authorized visitors, eg that the name on ID card in this case is Joe Biden.


Can I scan with nmap from cloud services?

You can do network scans from AWS services, but you need to fill out a request form; otherwise, you will breach their acceptable use policy.  You can find more information about the actual request process here https://aws.amazon.com/security/penetration-testing/


How will SHA1 deprecation affect SHA1 roots in OS/Browser trust stores.

(Edit 2014-11-25: Reworded flushed out to phased out.)
Short answer: From what I can tell, they will be gracefully phased out, not flushed out. (At least by Microsoft.) The old SHA1 root certs will expire regularly and Microsoft will no longer accept NEW SHA1-roots starting 2016. The old ones will stay in I guess, since they were compliant to the guidelines when accepted into their root CA program. -- The other 3 organisations I looked at had no limits on SHA1 roots.

Microsoft
Microsoft will no longer accept SHA1 for their root CAs after the end of 2015.
http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx

  Digest Algorithms
  SHA1 (until 1 Jan 2016)
  SHA2 (SHA256, SHA384, SHA512)

They did the same thing with MD5 a while back.
http://technet.microsoft.com/en-us/library/cc751157.aspx

  Hash algorithm must be at least SHA1. No MD2, MD4 or MD5 hashes accepted.

CABForum
CABForum disallows MD5 in roots starting 2010. But SHA-1 is (as of yet) still allowed for root CAs. (So while there is no security reason to mandate any digest algorithm the root CA self signature this shows that it has in fact been mandated before.)
https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf

  Certificates MUST meet the following requirements for algorithm type and key size.
  Digest algorithm: Validity period beginning on or before 31 Dec 2010:
  MD5 (NOT RECOMMENDED), SHA-1, SHA-256, SHA-384 or SHA- 512
  Digest algorithm: Validity period beginning after 31 Dec 2010  SHA-1*, SHA-256, SHA-384 or SHA-512

Apple
Couldn't find a rule against SHA1 there.
Apple don't mention SHA2 in their root CA requirements. Instead they require a SHA1 fingerprint on the application form.
https://www.apple.com/certificateauthority/ca_program.html
But since there are SHA-256 certs already in their store this seems to be a formal detail of the application form only.
See Yosemite included root CA certs here: http://support.apple.com/en-us/HT202858

Mozilla
Couldn't find a rule against SHA1 there.
Mozilla requires a SHA1 fingerprint on the application form.
https://wiki.mozilla.org/CA:How_to_apply
And, like with Apple: But since there are SHA-256 certs already inside their store this seems to be a formal detail of the application form only.
See Mozilla included root CA certs here: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/


How effective is changing the MAC address?

What you're referring to is fingerprinting - the act of identifying a system based on certain properties it has.

Modern fingerprinting techniques involve quite a few tests:

MAC address range
How the OS responds to certain packet flags (e.g. unexpected TCP RST+FIN)
Open ports and available services (e.g. remote X and SSH ports open implies it's not Windows)
Service banners - lots of services give away what OS is running, e.g. MySQL protocol header, or the Apache default 404 response.

Changing just one of these is unlikely to throw off a detailed fingerprinting scan.

If you really want to get into the details of it, take a look at nmap's "Remote OS Detection" documentation.


Replacement for DVL (Damn Vulnerable Linux)?

There are stacks: Metasploitable, DVWA, BWaPP, Mutillidae, WebGOAT (although the last few are vulnerable web apps).

There is also Hack.Me, a community project where people upload vulnerable sandboxes for others to practice against.

26/10/17 Edit to add: Vulnhub is a great resource for vulnerable & practice VMs. Meant to add this ages ago, apologies.

Troy Hunt has an online vulnerable web app to test against: http://hackyourselffirst.troyhunt.com

Alternatively, you could pay for access to Muts' student network (the gang that have released Kali - Offensive Security is the thing to search for.

There's loads of them around :)


Is it safe to open word document sent in email in LibreOffice

By design, LibreOffice will not execute macros that are not signed or are signed by an untrusted party without prompting the user and giving a security warning.

I am not aware of any exploits that override that, you may be alright.

It is still good practice not to accept documents from strangers, however.


How can hash keys of downloadable binaries be useful if a website has been compromised?

if a server has been compromise you should not download any content of it in general, keep in mind that the binary and the hashes (sha256, md5sum, blake2s or whatever) are potentially suspicious of been changed.


Yes, the application is vulnerable to Side Channel Data Leakage.

Words entered by a user via the keyboard are stored in the Android user dictionary(/data/data/com.android.providers.userdictionary/databases/user_dict.db) for future auto-correction. The user dictionary is available to any app without requiring any permission and this could lead to sensitive data being leaked.

It is recommended that for the sensitive data inputs the XML attribute android:inputType should be set with the constants such as textPassword, textVisiblePassword, etc. in order to prevent the sensitive data caching by the keyboard.


Forgot password best practice for mobile applications

You could ask for details about the actions the user has performed in your app.

Example: Show users a list of 3 popular merchants in the region out of which only one is used regularly by the user. Ask the user to select the merchant he has regularly paid using your app.

Options for trusted contacts like Facebook. The user can assign trusted friends or family members who will each receive a part of a recovery code if the user forgets the password.


The statement is weird, because it comes from a knee-jerk ritualistic reflex about key lengths.

The full text from the page is:

  Specifies the length in bytes of the output that will be generated. Typically, the key length should be larger than or equal to the output length of the underlying digest function, otherwise an attacker could simply try to brute-force the key. According to PKCS#5, security is limited by the output length of the underlying digest function, i.e. security is not improved if a key length strictly larger than the digest output length is chosen. Therefore, when using PKCS5 for password storage, it suffices to store values equal to the digest output length, nothing is gained by storing larger values.

There's some confusion here, indeed. Let's see the details:

PBKDF2 is a Key Derivation Function: its output can have a configurable length, and is meant to be a "key".
Key for cryptography must not be too small, to avoid being inherently weak. For instance, a DES key, being 56-bit long (ok, 64 bits, but 8 bits are ignored, so 56 "real" bits). However, beyond about 100 bits, exhaustive search is so ludicrously expensive that it ceases to become a threat.
Similarly, PBKDF2 can be "attacked" with an effort of cost 2n if the underlying hash function has an output of n bits. This is totally unfeasible even if using MD5 (128 bits are already enough for that). But, in a certain bureaucratic light, PBKDF2 has "strength n bits".

So the reasoning goes: if you use PBKDF2 to generate a key which is not of at least n bits, then your key is "weaker" than what PBKDF2 could have produced.
Now it would be kind of stupid to refuse to generate a 128-bit key with PBKDF2/SHA-256 because SHA-256 offers "256-bit security". But it makes some kind of twisted sense, if seen through a procedural prism by a frustrated auditor who does not have a clue about what a key actually is.

Summary: ignore that weird passage of the doc. Use PBKDF2 with HMAC/SHA-256 or HMAC/SHA-512, whichever floats your boat (SHA-512 might be slightly stronger against attacker who use GPU as they are sold in early 2013, because current GPU are bad at doing 64-bit arithmetic). Generate the key length that you need for the algorithm at hand. 128 bits are anyway more than enough for symmetric keys.


CISCO VPN Client - Gateway's fingerprint has changed - what is the risk of simply accepting the change?

The fingerprint changed because the server side certificate changed. This can mean that your IT department has changed the certificate on the server. If it is every 3 months, it is quite likely that this is the case.

Alternatively, if this message appears, someone else is acting as you VPN server and does not have the correct certificate to create the same fingerprint as before. This warning is then a clear indication that you are sending your credentials to a malicious VPN server.

To be safe, always contact the system administrator if you see such a warning. In HTTPS, there are mechanisms which make it very hard to even ignore these types of warnings.


Before I answer your questions, here are a few principles that will make the answers easier to understand.

Keep network usage to a minimum. All transmissions are vulnerabilities. You are using the network to synchronize passwords between devices. All of the other functions should be performed locally on a cached database.
Sensitive data should stay encrypted whenever possible. Whenever data is not being used, leave it encrypted. Even in memory. Plaintext passwords are naked targets. They should only exist for the brief moments when the user needs them.
Hiding secrets is not the only goal of cryptography. There are four goals in cryptography: confidentiality (hiding secrets); authenticity (verifying that people are who they say they are, and things are from where they say they're from); integrity (verifying that data has not been corrupted); and non-repudiation (don't worry about this one for now).

Now to your questions.

1. Question

  should I decrypt the passwords on the server and send them plain text by SSL or should I send the encrypted password and encrypted private key and let the extension decrypt both.

The local application should decrypt both. Remember, we are only using the network to synchronize data between devices. Everything else should be done locally.

The user's whole archive of passwords should be cached on their local device. They are stored encrypted by the user's password (and key or whatever). When the user logs into the password manager application, he gives the application his password and/or key. This gives the password manager application the power to decrypt the database and read the user's passwords.

Basically, the answer is that you do need to decrypt the passwords in JavaScript. But you shouldn't be getting them from the server unless your local cache needs an update.

  the problem here is that Java and JavaScript Crypto Libraries aren't creating them the same, so I might need to call a java application from the extension.

No, you don't need to call a Java application from JavaScript. The cryptographic standards you're using are completely interoperable. If you aren't able to make them work together, then you're probably making a mistake.

2. Question

  I'm currently using RSA/ECB/PKCS1Padding as the Algorithm for encrypting text with public and private keys, I know, there is also AES, but I need public/private keys for my application, and therefore I want to ask if this algorithm is secure enough for saving passwords.

The first thing you need to know about this is that you probably are still using AES encryption. Symmetric encryption is an important part of asymmetric encryption. RSA keys are not capable of encrypting more than a few hundred bytes. Here's the basic procedure.

Encryption

Generate symmetric key A
Encrypt message M using A
Use the public RSA key to encrypt A
Send A+M (both encrypted) to the recipient

Decryption

Decrypt A using private RSA key.
Decrypt M using A

Also, your question about whether RSA is strong enough is impossible to answer. It depends on your teacher's standards.

3. Question

  is there anything that is better in the Java Standard Library

Yes. I don't know what is strong enough for your teacher. But Java certainly has stronger options.

SHA1 is the weakest of all the SHAs. The strongest of all the SHAs is SHA3-512. Adding HMAC makes it even stronger. AES is also much stronger than DES. PBE is kind of ambiguous. I usually prefer to specify PBKDF2 if I need something very strong.


It may be possible for example.com's JavaScript to make XHR requests to maliciousthirdparty.net. By default this is blocked due to the same-origin policy, but maliciousthirdparty.net can send CORS headers to allow the requests.

If you block XHR requests to the domain while allowing scripts to be loaded from it, it may make it more difficult for a malicious script to exfiltrate data. This could be useful for example if you don't trust the CDN hosting a JavaScript library that example.com requires to function properly.


Is running software in Docker an allowable way to bypass FIPS 140-2 issues?

You are basically asking if it is ok to ignore FIPS 140-2 requirements for a specific task, the actual way you do this does really not matter. It is unknown if this is acceptable or not in your specific use case. But at least you can no longer claim that all the cryptographic operations you do on the machine conform to FIPS 140-2 requirements.


Does Outlook store plain-text passwords?

Well, we will probably never be completely sure as we don't have the code. But we can discuss some possibilities. But first,
Why the change, actually?
What could be a reason for this change anyway? A possibility is that intelligence agencies had something to do with this, like is assumed to have happened with an older version of A5/1, Comp128v2, where the first ten bits of a 'random' key were always set to 0. Like this they can, if they get the hash from MS, just brute-force faster.
In case you don't like complot theories, another option is of course that MS doesn't want you to forget your password.
But let's look at the possibilities.
Passwords stored in plaintext
It is possible that MS stored plaintext passwords, but it would be a huge failure and I suppose (and truly hope) this is not the case.
Normally passwords are hashed and salted in an irreversible way so that even MS can't get to know your password from the value in the database. So how did they do this?
Two versions of a hash function stored parallel
What would be a possibility is that they already planned for longer time to have a maximum length on the password. Then, they could wait for you to login and, parallel to checking if you're actually typing in the correct password and logging you in, cutting off your input and salting and hashing that and store it somewhere else. At the moment they changed to the new system, they just copied the new hashes.
The passwords were always 16-chars truncated
As pointed out by Ajedi32 in the comments, it's also a possibility the passwords were always truncated after 16 characters already. (The reason for this, again, could be interference by intelligence.) The only difference is that MS now doesn't allow you to enter more, because they've become too lazy to truncate it themselves.
This doesn't seem likely to me, because if this were true, then why would they now tell the users to not enter more than 16 characters? Yes, it could be that things like this (i.e. UI texts are changed without an actual change of the function) just happen in a huge organization. However, as Ajedi32 explains:

Maybe they finally realized that not telling users about such an important security limitation was a bad idea, and decided to start explicitly enforcing the 16-character limit? Or perhaps they're preparing to lift the limitation in the future, and they need to start preparing users for that now? (Because lifting the limitation would mean that "1234567890123456" would no longer be the same password as "1234567890123456789")

The actual answer
As it turns out, Ajedi32 was right and passwords were always truncated, as pointed out in this MS article (credits go to PwdRsch, see the comments). The other possibilities remain here for theory's sake.


What is better, an established framework or a homebrew solution?

You certainly want your code to be written by the most skilled developer possible, but that's not enough.  Even the most competent developers make mistakes (though less competent ones obviously tend to make more mistakes).

To get relatively mistake-free code and algorithms, you want to start out with the cleanest code possible, but that's only half the process. The best way to eliminate faults is to have as many skilled developers as possible comb through the code looking for them. This holds true for code as much as it does for algorithms. Your solution needs to be widely vetted by the most experienced people possible.

Where you start -- the skill level of the original developer -- is just the starting point. After sufficient review, it doesn't really matter how skilled the original developer was.

So here's the key: the security value in any code is in how well-vetted it is. Whether it was written by you, by a renowned cryptographer, a large corporation, or nobody in particular, all that matters is how many skilled eyes have scrutinized the code.

Such a rule tends to favor established frameworks over homespun solutions. But established is not necessarily the same as vetted, which is part of why many security experts tend to favor open-source solutions: it's difficult for an open-source project to become popular without it being subjected to a certain amount of scrutany.


follow up to previously answered "Escalating from Apache shell to root"

You don't have to be root to compile and execute code. Presumably your configuration limits access to the necessary compilation toolchain such that your user can't do it.

Attackers can get around this by pre-compiling the necessary binaries or by dropping a pre-compiled compiler or interpreter of their own onto the system.

Best to start out by getting to know your system, your user environment, the tools necessary for carrying out your workflow, and how your local permissions affect it all. THEN move on to understanding how exploits work. Because unless you understand the basics, that stuff isn't going to help.


JSSE is the support for SSL/TLS. It uses certificates but includes no code for generating certificates. And, more generally, there is no code in the stock JVM that supports producing new certificates. There is code for generating new key pairs and signing; from there, making self-signed certificates is "just" a matter of implementing some ASN.1 encoding/decoding, which is easier said than done.

Your best bet, in "full Java", is to use some third-party library or product that does the job. Bouncy Castle is a Java library that includes code for generating certificates. Alternatively, EJBCA is a complete PKI solution (written in Java) that, by definition, can generate certificates, because that's what Certification Authorities do.

The biggest hurdle with certificates is understanding what you are doing, because the X.509 standard is, when you come down to it, a Devil-spawned abomination meant to torture and fill with despair and sorrow security developers. What you want to do is, indeed, to run your own CA, so you'd better start with a CA solution which already irons out most of the tricky details, contrary to the OpenSSL command-line tool, which is rather low-level. You will still need to think, but at least you won't go mad in the attempt.


What risks are involved in exposing our home computers over the public internet?

Well, the general recommendation would probably be something along the lines of:

Put a firewall in front of your web server. Only allow the traffic you need to allow, and deny (drop or reject is largely a matter of preference) everything else. You have already done this, but there's more to it than just running firewall software.
Go over the software configuration with a fine-toothed comb. Especially consider anything related to file uploads, execution of code, and things like that.
Keep everything that is even potentially exposed to the Internet fully up to date. This includes the operating system, web server, anything served through it (remember that those PHP scripts that let you upload and view files are executable computer code that can have security-related bugs) and anything that those applications rely on (such as for example a database server).

Even in the best case, your setup will only ever be as secure as the least secure portion of whatever is accessible over the Internet. The instant you start accepting packets from the Internet rather than flat out blocking everything, there is always the risk that a bug in the operating system's TCP/IP stack, the software that handles the packets, or where the data coming in eventually ends up, could cause the computer to exhibit behavior other than that desired by you (A.K.A. a security breach of some kind).

As soon as a fix for a security-related problem becomes available, lots of eyes start going over it to see if they might be able to exploit what's been fixed for illicit purposes.

Any host connected to the Internet will see regular scans from various bots. Some are harmless; some are stupid enough to be essentially harmless; but some are actually potentially dangerous, and HTTP on port 80 is common enough that you should expect plenty of such traffic. That you don't have a host name pointing at your IP address doesn't change that fact. Which means that the web server and whatever is running on it will have to be able to deal with anything anyone can throw at it based on currently known security vulnerabilities in any web server software and version (since the attacker won't know exactly what you might be running).


Is CentOS a good choice from a security perspective?

The short answer is this: No, CentOS 5.6 is inherently no more or less secure than any other modern supported operating system. The long answer is a bit more complicated.

CentOS is the "Community" release of RedHat Enterprise Linux (RHEL). The differences between the two are fairly small so you can think of them as functionally equivalent, see the Wikipedia page for more information. The relationship between them is best described as a workflow; as RedHat releases packages, the CentOS maintainers full down the source rpms (ignoring any packages they need to for licensing reasons), rebrand and repackage for their own releases while maintaining version numbers. This history and workflow is important to your question.

RedHat's business is selling a stable product with support. Each major release of RedHat Linux is defined by a single kernel version, and often the versions of big packages such as Apache remain fairly stable. The RHEL team does, however, backport relevant security fixes. These backports are what allow the RHEL 5.x series to use kernel version 2.6.18 but still be patched. Due to the above relationship, this work also translates back to CentOS.

All that being said, given the work required to translate the packages one must expect a time lag between a RHEL release and a CentOS release. Normally the lag is fairly small, occasionally you will run into the situation that we had earlier this year when there was a couple of month lag between RHEL 5.6 and CentOS 5.6.

Going back to your question: Is CentOS a secure distribution? Is pinot grigio a good wine? How good is your admin? As I said in the beginning, "CentOS is inherently no more or less secure than any other modern, supported operating system." Any system can be hacked into. Just make sure you are following good practices and all of your other layers are in place.


Bypass escaped double quote

Based on your description this should work:

\");alert("xss

The " will be escaped as \", thus resulting in \\", which escapes the \, but not the ".

To prevent this, you would at the very least have to also escape \ as \\.

Bypass escaped double quote and double backslash to single backslash

Based on your comment, I'm assuming the actual relevant parts of the filtering work like this:

"  -> \"
\\ -> \

This isn't secure either. An injection might look like this:

\\\");alert(1

" will be escaped as \" in step 1 which leads us to \\\\", which is then transformed to \\" in step 2. You can't use double quotes in the injected string, but that's not a problem as XSS with single quotes or completely without quotes is perfectly possibly.

To secure this the double backslash would need to be escaped, not transformed to a single one, which would give us \\\\\\\\\" with the above described injection, which is safe.


Ransomware in virtual machines. Running Locky for testing security measures

Many instances of modern malware are VM-aware to make exactly such examinations more difficult. The malware will attempt to detect if it is running inside a VM as one of its first functions and then simply terminate if that is the case. This will be done prior to the remainder of the payload being decrypted in order to expose as little as possible to forensics examiners.

I don't know about Locky in particular, but it would not be surprising in the least if Locky's authors were using this very common tactic.

See here for a good overview of this phenomenon:
https://blog.malwarebytes.org/intelligence/2014/02/a-look-at-malware-with-virtual-machine-detection/


CA signature algorithm vs certificate public key algorithm

The signature created by the issuer of the certificate is fully independent of the algorithm used in the certificates public key. The signature algorithm instead depends on the issuers key and not the certificates key. It is actually common to have certificates containing an ECC key signed with RSA.


Securing Publicly Exposed MySQL Database for Group CS Project

the easiest way, if all machines are linux/unix-based, is to create ssh-tunnels (sometimes called 'poor mans vpn') from every machine onto your mysql-server;

no need to open ports to the outside
no need to create additional users
no need to change mysql access-permission locally
you can work with ssh-keys
data-transfer is encrypted

ssh -p 22 -L 3306:127.0.0.1:3306 user@mysql-server -N

this will start a tunnel and make mysql @ mysql-server locally available @ localhost:3306


Is DNSSEC really useless if TLS is properly configured?

TL;TR: In some use cases like HTTPS (web) DNSSec is not really needed. In other use cases like SMTP (mail) DNS spoofing will not be noticed by TLS, that is man-in-the-middle is possible if DNS can be spoofed even if TLS itself is properly used.

Details:

When used within HTTPS (web) and the currently established CA system you don't need DNSSec, because the browser checks the name in the URL against the name in the certificate and validates the trust chain using a locally stored (pre-trusted) root-CA. But note that the proper issuing of the certificate itself might be affected by DNS spoofing (see below).

With SMTP (mail transport) the situation is different. To get the next hop within mail delivery a mail transfer agent (MTA) must know which server is responsible for which recipient domain. This is done by looking up the MX record in DNS. If this record can be spoofed (which can be done without DNSSec) then the MTA will deliver the mail to the wrong mail server. Even if delivery is done with TLS the sending MTA will not notice if the MX reports the attackers server as target server, because the hostname of the attackers server and the name inside the certificate will still match. A mechanism similar to MX for mail exists for SIP (VoIP) in the form of SRV records and it has thus the same problems.

Apart from that there are other protocols which rely on secured DNS. The most prominent is probable DANE which tries to replace the currently used but broken CA system with a system where the expected certificate is stored at the same place as the hostname, that is inside the DNS. The same way you could also store SSH host keys.

Also, in the current system with public pre-trusted CA most of the identity checks done when issuing a domain validated certificate can be forged if the attacker is able to do DNS spoofing at the right place. This includes the case where the domain validation is done with mail or where the validation is done by accessing a specific file on the site with HTTP only (because the site has no HTTPS yet). While in the first case the MX record will need to be spoofed you need to spoof A/AAAA or CNAME records in the second case. And once the attacker has got the certificate for the site in question the MITM attack against the site will not be noticed any longer.


Why would Amazon include an already trusted Root CA in the bug report they filed to get into Mozilla's truststore?

See comment #9 on that bug from Peter Bowen at Amazon:

  It also includes one additional root CA already in the Mozilla program which we wish to have enabled for EV certificate issuance.

That suggests that the root was already included in NSS, but not enabled to issue EV certificates; this is a request to change that.

Quote from comment #21:

  I am now opening the public discussion period for this request from Amazon to enable EV treatment for the currently-included “Starfield Services Root Certificate Authority - G2 certificate, and to include the following 4 new root certificates, turn on the Email and Websites trust bits for them, and enable EV treatment for all of them.


How does LiveID work? Is there any documentation on the LiveID provisioning site msm.live.com?

LiveID is an extension of WS-Trust/Federation/Security in a passive mode.  Passive meaning that the client -- the browser -- needs to be told what to do by the clients, which is done through 302 redirects and POST-backs.

To rephrase this, LiveID follows a Claims-Based model, building on top of the protocols mentioned earlier.  The documentation is very sparse because, well, Microsoft can be very lame at times.

The differences between the versions have to do with how the authentication happens, moreso what layer makes the redirect to login.live.com.  E.g. the server-side code forcing the redirect, or the client code -- javascript -- does the redirect.

What exactly are you trying to accomplish?  Are you just wanting a person to log into your site using their LiveID, or are you looking for a more in depth federation model?