Does a commercially available self destructing HDD (set in BIOS) exist? Does a self destructing HDD (physically destruction) that will destroy after a certain time exist, or when I use some software to initiate its self-destruction?

I guess it need to be set in BIOS or on some other "lower" level?

I mean, a HDD that I can buy as a casual customer, and I don't need to be part of a government or some agency.

Why I would want something like that?

If somebody stole my laptop and accessed my data using the right password, then after 24h I want to destroy the HDD, unless the attacker knows that I have set my HDD to self-destruct on some BIOS-level, and re-enable the next 24 or 48 or some other time hour period e.t.c. But this is just an example, in reality it could be done differently.

There is no hard disk drive, or a solid state drive, or any other non-volatile computer memory on the market that would have self-destruct capabilities and a casual customer could buy. There's also a good reason for this. Let's, as an example, see what a military grade RunCore's InVincible SSD does:

                     XBitLabs.com: RunCore InVincible SSD Features Physical Self Destruction Capability

  Besides typical elimination of all data through overwriting, the
  InVincible SSD can completely destroy the data by physically
  destroying memory and other chips inside the drive by burning chips
  down physically.

  The RunCore InVincible SSDs allow to protect sensitive data from third
  party access in two ways with a single click. One method is an
  intelligent elimination of all the data by overwriting the entire disk
  with meaningless code. This overwrite-deletion method ensures that
  there is no way to potentially recover previous data stored to the
  device, effectively setting the SSD back to factory default. Still,
  there are various data recovery devices not available commercially
  which can, perhaps, recover data even after overwriting.

  A less subtle method is the physical destruction of memory chips
  inside SSD by applying an over-current to the NAND flash memory and
  thereby physically destroying them.

Here is a YouTube video presentation from the manufacturer.

But let's make one thing perfectly clear. I'm not in any way endorsing this product. In fact, I don't know of a single store that would be selling them, the presentation documentation and the video are lacking on detail, credibility* and quality. And all of it was a bit of a joke among friends back when this story hit the web. If you watch the presentation video, you'll see what I mean for yourself.

But let's for a minute assume this drive is real, and it does what it says on the box. Would you be able to buy it as a casual customer? No:

This is supposedly how the circuitry looks like after self-destruction. There's been a lot of speculation on the web this image (the only one you'll find) was faked. I can't say it doesn't look like it was faked to me also. Note the PCB assembly helper lines (white) next to the storage chips that seem to have melted too.

  RunCore positions its InVincible SSDs for aerospace, military and
  general industrial applications, it is unclear whether the company
  plans to sell such SSDs to general public and whether the company will
  be allowed to do so.

There's a good reason for that too, considering it's at the very least a fire hazard, and if you'd use it in your laptop, let's not even consider what all would start happening, if you forgot about it and wanted to board an airplane (although same should be true for any other public transportation vehicles, possibly public places too).

* I didn't manage to find a single proof this product actually exists, or that the presentation slides and video were not faked, possibly as a demonstration of planned capabilities for military contractors.


Downloading list of pinned certificates I'm thinking about implementing certificate pinning in a mobile app. The app will need to connect to several secure sites. Rather than having to update the app every time one of their certificates expire, would it make sense to:

create a self-signed cert with an expiration date far in the future
publish a list of valid certs for the app, on a server that uses that self-signed cert
pin this self-signed cert in the app
when the app launches, download that list, and start pinning the additional certs in it

Or is there any reason this would be a bad idea?

What you are describing is actually your own, reduced auto-update feature, limited to updating what amounts to a "trust store" for certificates.

The bad thing about it is that it works outside of the normal app update mechanism, without much possible user intervention, so the user will get the updates whether he wants them or not.

The good thing about it is that it works outside of the normal app update mechanism, without needing user intervention, so the user will get the updates even if he believed that he could live without them.

Google Chrome has been doing just that for some time, and even update the actual software code, not just the trust stores; and it seems to work well with them. As @mikeazo comments, if your "root private key" (the private key for your self-signed certificate) ever gets stolen, you are in deep trouble, so maybe you should use a signature strategy: instead of making your server be some HTTPS server (with the self-signed certificate for SSL), make it a plain HTTP server, but have the "list of valid certs" be a signed piece of data. That way, you can handle the signature process on a distinct machine, preferably an offline computer (if the private key never leaves a computer which is never linked to any network, then chances are that the private key will not be compromised remotely).


Can I detect malware download using Wireshark? I have been working on Wireshark lately. I am learning about malware behavior, but I am curious to know whether methods exist to detect malware download (via drive-by download) on systems.

Anti-virus program catch them, but however, is it possible that we can actually see one those malware that get downloaded (using Wireshark)? What notifications in Wireshark help us identify them?

The response is Yes, basically what you are referring is a NIDS (network intrusions detection system), bear in mind that Wireshark is not an NDIS, so in this case you will need to do the detection/analysis by your self.

Not all the cases for detect malware are covered by a NIDS and depends on the features of the system in place, but from the perspective of the network you can detect a very high percentage of malware. Obviously, depends a lot of the type of malware you want to detect, for example if a user downloads from a site a executable file with malware over a TLS connection a NDIS is not effectively, that's why is good to have an AV.

A good source of samples is lists.emergingthreats.net if you want to play with wireshark and pcap files with malware.


What's the point of providing file checksums for verifying downloads? Many projects offering binaries, also offer hashes (e.g. SHA256) of those binaries, wither as .ASC files, or directly on the web page near the binary. This isn't to protect against network-caused corruption, as that's ensured by the TCP protocol.
Given that the binary and the hash are downloaded from the same server (example from very sensitive software, bitcoin-core), what attack scenarios does this technique prevent?
If an attacker managed to tamper with the binary, why wouldn't they be able to change the checksum in the same way? Same for the attacker performing MITM and tampering the download in transit.
Note that I'm not talking about public/private key signing, which is far more secure because the attacker would also need to get the signer's private key. I'm only talking about the point of providing checksums/hashes along with downloads. This is even stranger for bitcoin-core, which has both the mechanisms and the audience to sign the file with a private key.
I can imagine that a separate, secret, monitoring bot hosted on a completely different system, could download the signature file every minute (given its tiny size) and check it against tampering, but I haven't heard of this being done.

It allows distribution of the bulk data through untrusted channels.
For example, you could give me an USB stick and ask me to download it for you over night using my cheap DSL connection, while you get the checksum off the webpage (that you pulled up on your laptop with an expensive metered connection). I recognize the file name, look into my "large files I have downloaded already" folder, and there it is, so I copy it onto your USB stick.
You get the file instantly, and you don't have to trust me for this to work.


Security BY obscurity is horrible. Is security AND obscurity good? Normally I preach that rolling your own custom crypto algorithm is a bad idea.   But will it really hurt if it's the outermost layer though?  Or will it make security worse?

AES -> CipherText -> CustomEncryptionAlgorithm-> CipherText

I'm thinking that the extra layer will help.  Let's say even if CustomEncryptionAlgorithm is bug ridden mess, it can't possibly make things worse.  That's because AES output is already indistinguishable from random noise.

On the other hand, something tells me that the following is problematic

CustomEncryptionAlgorithm -> CipherText -> AES -> CipherText

Is it bad? and why?

Please don't comment on company resources spent on security vs obscurity etc (I agree security comes out ahead)  I am more interested in understanding the cryptographic theory behind vulnerabilities in this approach.

Don't roll your own crypto!
From a purely cryptographic point of view, any length-preserving bijective function cannot reduce security. In fact, even the identity function, defined as f(x) = x, will not reduce security, assuming the keys used for the standard cipher and your homebrew cipher are mutually independent. The only possible way it could reduce security is if your homebrew function does not use a different, independent key and leaks the key in the ciphertext, for example with fk(x) = x ⊕ k done on each individual block of input x, a classic XOR cipher vulnerable to known-plaintext attacks.
From a practical standpoint, there are gotchas that can matter. I mentioned length-preserving above for good reason. A compression function is still a function, and sometimes compression and encryption can lead to very bad results. This is partially why your second example, with your custom algorithm applied before standard encryption, is indeed worse. It can leak information about the plaintext through length. There can also be bugs in your implementation that result in other security vulnerabilities. From a purely theoretical point of view, they are out-of-scope.

It was pointed out to me in a comment that I may not be sufficiently emphasizing just how bad of an idea this is. While it may be fine in theory, the real world works differently. Actually using your own homebrew crypto is a very bad idea, no matter how you use it. The only time you should ever actually do this is if you are a professional cryptographer. Bernstein can do this. Rivest can do this. Rijmen can do this. You cannot. Don't shoot yourself in the foot and instead use proper algorithms.


Admin privileges depending on JWT body From a security perspective is it ok to store the permissions of a user inside the body of the Json Web Token?
For example a jwt body like this:

{
   "username": "lukas",
   "isAdmin": true
}

The integrity of the body is verified by the signature of the token so I think it is no problem to use this technique but as it is really security relevant I want to ensure whether my thoughts are right.

It depends on what scenarios are relevant in your case, it depends on architecture that you want to implement. Some examples:

1) If in your case the risk of compromising of account with low permissions is higher compared to accounts with high permissions, then sending permission info in the token increases your risks.

2) If in your case all accounts can be equally easy (or equally hard) compromised, then sending permission info doesn't change your risks: The attacker will compromise an account with high permissions (e.g. admin account) and, even if permission/authorization logic is embedded in the application not in the token, he will get all permissions of this account.

3) If in your architecture you want to have "slim" application modules / services, that provide as high performance as possible, as small response times as possible, use as little resources as possible, or if integration with authorization / permission system is too expensive, then may be you want to eliminate any logic related to authorization / permissions in the modules / services that implement business logic. On some nodes you can deploy authentication and authorization services. On many other nodes you deploy (or run containers, doesn't matter) services that implement some business logic. And you may want that these services don't care about permissions and just trust the tokens that the other part of your application issued. Then sending permissions within tokens could be a good approach.


Receiving a response that is PGP encrypted I work as a software engineer, yet with limited experience in cryptography. I have a practical issue, not so much a technical question, related to a PGP-encrypted mail exchange I've had.
Lately, I have uncovered upon own initiative a flaw in the web login interface of a bank, which flaw I plan to not further disclose in public.

The bank in question features a responsible disclosure program in which anyone can report issues over email, given that the message (body) in the mail is encrypted using a public PGP key provided. As such, I have formulated the report and encrypted the message (Version: BCPG C# v1.6.1.0), and sent the PGP message from Gmail.

Several days later I receive a response in Gmail with no mail body, yet with 3 attachments:

1 format-less file containing a PGP-message
1 format-less file containing only "Version: 1"
1 .eml file  that features meta-data and again, the PGP-message which I believe is the response. See attachment below.

However, I am puzzled by how I would be suppose to decrypt their response, for the simple fact I miss the private key. Furthermore, in my initial report I did not propose a new means for future communication or public key of my own to allow them to respond.
I have responded with a new message, encrypted using again their public PGP key, but have received no response any more since weeks.

Lastly, I have attempted to run their message through https://cirw.in/gpg-decoder to (at least) check information-contents of the keyblock but receive a "invalid packet format".

What am I missing? Perhaps a fundamental lack of knowledge on my end makes me oversee something? Guidance or advice here is more than welcome.

EML attachment contents:

It should have been encrypted using your public key, so simply decrypt with your private key.


Does EFS protect against data theft by ransomware? Recent ransomware events often include data theft in addition to just encrypting data. The Encrypting File System on Windows Pro/Enterprise editions encrypts individual files using a private key stored alongside certificates for that user account. The file is therefore unreadable by anyone except the logged-in user account. When you copy the file to a flash drive, it remains encrypted. The only way to read the file on another computer is to also copy the certificate + private key.
Therefore, if ransomware simply uploads your files, wouldn't they remain encrypted with EFS and thus unreadable by attackers?
This wouldn't prevent the ransomware from encrypting your files, but would it prevent threats of public leaks/selling of stolen data?
Edit: Assuming Windows 10, and assuming ransomware runs on the user account that can access the EFS-encrypted files.

When you copy the file to a flash drive, it remains encrypted

When EFS-encrypted file is copied to a drive that do no support encryption (FAT/exFAT families), the file is decrypted before copied and copy is unencrypted. I believe that only NTFS-formatted drives support encrypted file copy.
If you attempt to ZIP the file, it is decrypted first and then zipped (encrypted files does not support compression). In other words, transferring EFS files removes the encryption.
This means that if attackers run something under your account which can decrypt the file, then attacker can get to raw unencrypted content.
The purpose of EFS is to provide security for offline (when you are not logged on) and other user access (locally or remotely).


Verifying cryptographically signed files when the key has been revoked This is mostly a question out of idle curiousity. If I use my private key to sign a file today, forming a signature, and distribute that signature with the document to someone they can then use my public key (which they've obtained out-of-band in a secure manner) and the signature and verify the document remains unaltered. So far so good.

But if the verification step only happens some time later, and in the mean time I revoke my key, how should this be handled?

On the one hand, the file was signed in good faith at a particular time and if the file is somehow timestamped and the timestamp is before the date of revocation and the revocation is not because of a compromised key, then the revocation shouldn't automatically mean distrust of the signature.

On the other hand, assuming the key was revoked because it was compromised, someone else could have used my compromised private key to sign a file with a false timestamp within the placing in within the active period of the key.

As far as I understand, the longer a key stays 'active' the less secure it gets, because the more time there has been to brute force it and the more it has signed/encrypted, the more information is available to use in various attacks. Now I understand that theoretically brute forcing a key should take longer than it will take for the universe to suffer heat death, but it's always possible that short cuts may be found in the future. So I imagine one would want to revoke keys regularly.

Is there a way to tell the difference between the two situations described above?

Is there way to tell the differences between a revocation because of cycling and a revocation because of compromise?

It seems (from this question) that regular key revocation is not longer best practice, but I'm not 100% sure I'm reading that right. Instead Trust-on-first-use and "pinning" are used in practice today. Also the answers and comments in said question make it clear that there's no mechanism to expire a key. Having done some brief reading on TOFU and pinning though, and it doesn't seem to influence my question.

To prevent this being closed with an "XY" complaint, let me be more explicit. In the situation of a compromised key mentioned above, I can't think of of a way to reliably verify the document even though it was signed by an at-the-time uncompromised key. This could very easily be a gap in my knowledge, and I want to know if there are techniques to still do this reliably?

Is there way to tell the differences between a revocation because of
  cycling and a revocation because of compromise?

Certificates.
Certificates usually include validility times, during which the associated public key is valid for use. Most certificates are issued for 1 up to 3 years and afterwards you need to cycle the certificate (and also maybe the associated key). With most better TOFU and pinning schemes you will still see and check the certificate and not solely trust on the pinned key, to ensure that the key is actually still valid and not expired nor revoked (which is handled via OCSP and CRLs).

  But if the verification step only happens some time later, and in the
  mean time I revoke my key, how should this be handled?

This is actually a tricky problem, that requires some (2) changes to the way documents and data is signed and verified.

First, we need to change the OCSP responders. Right now, you usually only get "good", "unknown", "revoked" or "suspended" from the CA as an answer. This is clearly not enough, as you need to know when the certificate was revoked or suspended. Given this information you can actually check if the signature was issued before the key was compromised. Of course this still leaves the issue that anybody could just use a pre-revokation date for signing data.

To fix this issue, you need some more reliable way of time-stamping data than by letting the time stamp be created by the signer. You need to outsoure the timestamp, by either letting a trusted service sign a combination of the hash and the current time, by cleverly chaining the hashes like is done with Certificate Transparency or by insert an entry into the block chain.

As soon as you have a (valid-looking) signature with a trusted time stamp before the revokation date, you can rest assured that the signature is valid, but note that your signature should be included by the hash sent to the time stamping service to ensure nobody ripped it off and replaced it.

The alternative possible solution is to get rid off this whole revokation system and just (exclusively) use short-lived certificates where you can be sure that if it was revoked, that all the data in this short time frame could have been signed maliciously.


Command to check a website is vulnerable to Logjam I am referring this post https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ and trying to see a website is vulnerable to Logjam or not.

I try with www.google.com:443 but I am getting Server Temp Key: X25519, 253 bits. Does this mean Google is vulnerable to LogJam?

(The command to use is $ openssl s_client -connect www.example.com:443 -cipher "EDH")

I would like to try this in my SIT IP and port, which is not open to public, so I am not sure the way I do is correct or not.

As my understanding, Google will not likely be vulnerable to Logjam, right?

If you have a better way to verify, kindly advise.

The easiest method would be to use testssl.sh on a Linux system that can access the site. The command below will give you plenty of information about the security of your TLS implementation, including whether or not it is vulnerable to LOGJAM:
./testssl.sh https://yourSIT-IP.com:yourPort

If you just want to test LOGJAM specifically
./testssl.sh https://yourSIT-IP.com:yourPort -J


Is this spam SMS containing an audio file dangerous? Yesterday I received a group text message from a number I don't know and opened it by mistake.  I was in a group chat with two other people, one in Pennsylvania one in Massachusetts. The message body was the phrase "knows what" and attached was a file called voicenote.amr.  The file was a 5 or so second clip of what sounded like paper rustling.

My question is what is the point of a spam text like that and what information could I have disclosed by accidentally opening it? I've gotten spam texts in the past but they are usually some sort of phishing.

EDIT: I am running Andriod version 4.4.4 and using the default texting app called "Messaging" it is also version 4.4.4. It handles both group and regular texts.

My guess is that the sender is trying to exploit the recent StageFright vulnerability, but since you have the latest Android security patches, you just got a dumb audio file.

If the attack had been successful, it would have gained root access to your phone and removed all traces of the original sms.


Security implications of storing encrypted snapshots on cloud We have to deliver a zero-knowledge SQLite based accounting/reviewing app running on Mac 10.6 and above.

We are asked to upload snapshots of database to cloud (AWS S3 or GCP) at regular intervals; so any accountant with right credentials can download the DB and start auditing with no geographical limitations.

We have decided to do the snapshots thing by uploading encrypted sqldiffs to the server. Also, once the auditing is complete, the entire DB is uploaded.

I am a junior programmer not a security guy, so it's probably none of my business but out of curiosity--

does the practice of storing hundereds of encrypted files, which in plain text would be like incremental diffs, undermine hidden-ness of the underlying data in any way?

In essence

I have patch files like so:

taken at 3.00 AM

alice

taken at 3.01 AM

alice
bianca
carolina

taken at 3.02 AM

alice
bianca
carolina
doofenshmirtz

Size of patch files is always less than 100 kB.
Patch files contain redundant data, just look at the examples.
Patch files are uploaded at every minute-of-operation.
Client probably has more threat from local (in nation) competitors than the giants.
All these patch files are encrypted client-side, using openssl, AES256 CBC.
Users (less than 50) would have to memorize the keys shared in person
We hadn't thought of changing password periodically but we plan to enforce the usual password requirements.

I am curious about the implications of points 1, 2, and 3.

does the practice of storing snapshots of encrypted sqldiffs undermine hidden-ness of the underlying plain text in any way?

Not quite clear what you are asking here. I assume that you are asking whether it is safe to store encrypted plaintext in the cloud?

The short answer is "maybe".

In theory, this may well be sufficiently safe for the risks it presents. Of course, only people familiar with those risks can realistically make a proper assessment so this answer should, in no way, be taken as a recommendation.

There are a number of potential issues that need to be considered when assessing the risk:

How protective is the encryption being used? Does it meet the latest standards?
How long a key is being used?
Is the passcode strong enough?
Is there only a single passcode? (reusing the same passcodes to encrypt different data can ultimately compromise the encryption).
How is the passcode/key managed? How is it shared? Who has access?
How long does the encrypted data stay online?
How valuable is the data? (is it worth attackers spending lots of time/money to get to the data)

I could go on but hopefully you can see the shape here.

Really, the question is not about putting encrypted data into the cloud, it is, as so often with security, about how things are managed and what is the overall risk and risk appetite.


How random token protect against CSRF Generally we know that a random token added to each request is a good solution against CSRF. But how exactely is it work? The web server generates token, sends it to client in hidden form, than this token is added to request and webserver validates it (for me it is reasonable). the second approach could be that client generate the token and sends it to web server. But how webserver know about the token, is it correct if it was not generated by webserver.

The token is always generated by the server, never the client.  You are correct that if the client generated the token, then the server could not verify that it was valid.   This is why every single CSRF mitigation scheme includes a token generated by the server.  So, since the server created the token, it always knows what the token value should be, and can validate that the client sent the correct token.


Relative importance of CHROOT for web servers I have read extremely mixed opinions on the process of chrooting for a web server (non-shared environment). Some people swear by it, yet others say that it isn't as secure as everyone says.

Given that chrooting can be difficult and time consuming to implement and maintain, on a non-shared server do you Chroot? Why/Why not?

If you do, do you use a module such as mod_security?

If you don't, do you do anything else to the server that accomplishes the same goal?

I disagree with the idea that chroot is difficult - it just isn't appropriate for everything. For a small environment, with a server hosting more than one web environment, chroot is exceedingly powerful and provides controls around separation, and escalation prevention. Managing it is not a huge resource problem.

If you have an enterprise scale environment you may be less likely to use chroot (as it does become unwieldy in a large environment), but you are likely to have alternative controls which may include in depth monitoring, IDS/IPS , layered firewalls and SIEM.

I would class mod_security as an essential (for the webservers that have it or equivalent functionality) - it is an extra layer of defence which is simple to implement, and for most use cases it doesn't cause significant impact.

chroot and mod_security - as well as firewalls etc are all just layers of security which may help to prevent an attack or at least slow it, thus raising the likelihood you will spot it before it causes too much damage (assuming you are also monitoring...another control)


Exectuting sudo command in one line within a non-tty shell I have access to a server via RCE over http. I can send post requests to the server which results in command execution. I am attempting to escalate privileges via sudo (su is not installed).

The server is heavily firewalled with egress filters and there are no writeable directories/files within the web application.

My objective is to experiment with the sudo command to escalate privileges but because the command execution is not TTY; I am unable to execute the sudo command.

Is it possible to execute a command like sudo -S in a non-TTY shell?

Maybe using python's pty module to spawn /bin/bash or /bin/sh, but what about a method to just execute a single binary with some parameters passed to it like sudo -S <command> within/as a TTY shell?

To summarize: Is there a way to run sudo in a single line in a non-TTY shell?

For example I am trying to run sudo with these parameters:

echo <password> | sudo -u root -S id

When I execute the above command I receive the following output:

sudo: sorry, you must have a tty to run sudo

There are probably a few different ways to approach this problem, but I believe I found a simple way around it that is no different from what you'd do normally to upgrade a shell to a full-fledged pty.

First, the reason you are encountering this error is due to the Defaults requiretty setting in /etc/sudoers. It seems this option is outdated, and is already likely removed/slated to be removed from the default configuration on most distros.

I created a test user "shudo" with password "shudo" who is allowed to sudo to root to run the command id, and enabled the requiretty option. Here's what happens when "shudo" tries to sudo from a netcat shell:

sudo id
sudo: sorry, you must have a tty to run sudo

To get around this, let's try a typical PTY upgrade using Python:

echo -e "sudo id\nshudo" | python -c 'import pty;pty.spawn("/bin/bash")'

There's probably a way to do it with the -S option, but it's not needed. This spawns a new PTY to run /bin/bash, which receives the sudo command and password as standard in.

Here's the output:

echo -e "sudo id\nshudo" | python -c 'import pty;pty.spawn("/bin/bash")'
shudo@mymachine:/tmp$ sudo id
[sudo] password for shudo:
uid=0(root) gid=0(root) groups=0(root)

You can see the new shell is spawned, sudo is executed, and the command is run as root! Note that this did leave my shell in a bad state since stdin is tied to the pipe, but it should be sufficient for a PoC.


What is the difference between 'Eavesdropping' and 'Remote Spying' in ISO/IEC 27005? In the Annex C of ISO/IEC 27005 typical threats are described, among others eavesdropping and remote spying. When searching on the internet for further description of the two terms I found them used synonymously.

So why are the two listed separately?

Eavesdropping

Reading sensitive information within a short range. In other words, eavesdropping.

For an instance, most credit cards come with a chip in their hearts. That makes it vulnerable to RFID attacks. Read this article RFID Credit Cards and Theft by Joel Johnson to know more.

Remote spying

Monitoring a device (which is not apparently yours) in another location, regardless of the range.

All you need is to gain access to remotely control the target device. A malware or a spying software on the target machine would do the needful.

You would be surprised to know Not just attackers use this to secretly monitor other devices, a lot of legal usage of this method is around us. Employers can monitor employees devices(since most of the devices are provided by the employer) and parents can use this to monitor their children(for safety purpose, etc.)


how to protect my linux pc from wifi sniffing I have a wifi shared connection with other flatmates and I'd like to know how can I protect my Debian pc from being sniffed. Should I use a wifi anti sniffer to detect if any wifi card is in promiscuous mode? in that case it's only to detect, but if no wifi cards are in promiscuous mode means that nobody is sniffing right? In the case that someone is sniffing, would be the only solution the use of a VPN to protect my packets? or is there another way to protect from sniffing?

Should I use a wifi anti sniffer...?

These work by detecting responses from the sniffing card - it's not hard to prevent any packets being sent out.

  would be the only solution the use of a VPN to protect my packets?

This doesn't stop the packets from being sniffed - it only prevents them from being read or modified. As such it's no different from other forms of encryption (e.g. SSH, SSL). You also need an end point for the VPN before you can access any services outwith the VPN. If you don't trust the people you live with, do you trust the people who manage the VPN end point? Although many routers have VPN capabities I've only ever seen this for the internet facing side - not the LAN side - so unless you know differently your only practical solution to the problem is to build your own router with VPN, DHCP, NAT.


Does allowing a user to know their own authorized capabilities decrease security? In a system with a complex set of computed authorizations, does conveniently allowing a given user access to view all of their own authorizations decrease security?

In a "Policy as Code" system which relies on consumers of its API to develop their own integrations, it seems like a wise idea to allow convenient viewing of ALL of user authorizations, because a given user can request access more easily and take advantage of "code as documentation", rather than pestering InfoSec for the state of their authorizations on an as-needed basis.

To block access to a comprehensive list of a user's own computed authorizations seems to me like a matter of "security through obscurity", since users can likely explore the system to find out what they can and cannot access.

This came up in a discussion I had with a coworker on the subject of this Vault mailing list post about Vault Policy viewing:

Inspect your own token's policies?

But it applies to a lot of other things. Anyway, I'm asking this question because I've been wrong before, I think it's premature for me to declare that "it's just obscurity":

How do I tell whether allowing a user to easily view ALL of his own authorizations will increase vulnerability?

Kerckhoff's principle applies here: it should not.

In theory, the list of user's privilege should match what the user is authorised to do. In practice, some oversight may cause you to grant a user more privilege than they really need, and disclosing authorisation information just makes it easier for them to figure that out.

The only drawback here is if the user is actually granted more access than they needed. Then the authorisation information may tip off the user that they have more privileges than they should have. Ultimately though, this isn't the problem caused by disclosing authorisation information, but rather the token's privilege was too broad to begin with.


Is it possible my Computer is part of a DDoS network, is there a way to tell? Title has it all. I consider myself a power user and a tiny bit more knowledgeable than the average Joe. Still I wonder sometimes if my computer might be part of a botnet without me knowing. Is there anyway I can tell if this is so ? (No evidence on my side, to support my concerns)

Yes, you can look for certain things to know whether your computer is being used as a botnet:

Look for unnecessary outgoing connections from your PC, using various windows or Linux or MAC(whichever you are using) tools.
Unnecessary programs running in your computer. Check the list of programs running currently, you may find something surprising maybe something you never started.
Lookout for sudden increase in outgoing traffic, Monitor outgoing traffic(graphs preferably) and check if you see spikes in them. Check their timestamps, are they regular and during same timestamps everyday?
And At last keep your computer protected so that no incoming connections can be made, and a good antivirus and antimalware is installed so that your computer can be protected from getting infected.

But as they say, You can never be too careful. You can just hope for the best :)


is there a workaround for CVE-2015-2625? we are not able to upgrade jdk 6 to jdk1.8u51 where this issue (CVE-2015-2625) is fixed.
is there a workaround one can have until we migrate to jdk1.8?

You ask for a workaround for "Unspecified vulnerability...allows remote attackers to affect confidentiality via vectors related to JSSE". Since the only information you find in this sentence is that it is somehow related to JSSE you are maybe safe if your application is not using JSSE.

Apart from that there were lots of critical fixes in Java and JDK6 is out of public updates since 02/2013. If you really depend on this version you might need to buy Premier Support from Oracle (ends 12/2015) or even extended support (ends 12/2018).


Firefox Account - Export user data (GDPR) Is there a way of exporting all user data associated with a Firefox Account?

Yes? where can I request/download it?
No? isn't right of access a legal requirement under
    the current GDPR legislation?

Examples of what I'm asking :

Google: Download your data
Facebook: Accessing & Downloading Your Information
GitHub: Download all of your data
LinkedIn - Accessing Your Account Data
Twitter - Your Twitter data

Yes - Right of access is a requirement under GDPR for EU residents, although it is not always implemented in the same way.

I would start with Mozilla's Privacy Policy which has a link to a form for Data Subject Access Requests at the end - that in turn has an option for Information Requests.

It also has a link to Information for EU, EEA, and Swiss users but that page doesn't seem to specifically address your question.


Recompute Rainbow table with salt? So, as I understand it, you prepend a password with salt before you hash it so that the resulting hash can't be used with a rainbow table to find the original password, as you could if the password alone was hashed. But what's to stop someone from recomputing a new rainbow table with the salt prepended if the salt is known? I thought knowing the salt wasn't supposed to matter security-wise?

One word: cost.

It is much more costly to built the table than to directly try to break the password. Trying to brute-force the password requires only a trivial amount of memory; a rainbow table requires a huge storage space.

The only point of a table is that someone else has computed it and you can now use it. Many people using one table (or the same person using the table several time) pays up for the cost of building that table. If you are going a table once (for one password), there is just no point.

If every password in a given (really big) password database was using the same salt, that would be a different story. But would be a gross misuse of the salt: the point is that every password uses a different salt, so a rainbow table can never pay up.

Salting does not imply that you cannot try to break-force the password directly. Not only you can, but it is not more difficult when there is a salt. What you cannot do is reuse previous computing efforts (unless the system so broken as to not be able to generate a different salt each time).


Multiple hidden volumes (VeraCrypt)? Why doesn't VeraCrypt support having more than one inner volume, each having its own password. It seems to me that someone could always use extortion to reveal the inner container password in addition to the outer one if they knew VeraCrypt well and how it works. By having more than one inner container you could even have a very small one with a special file in it and nobody would ever know how many inner hidden containers you have, so it seems to me that would be adding an extra layer of security. Comments welcome.

in you question concerning multiple inner hidden containers - you wrote

  nobody would ever know how many inner hidden containers you have,...

That would be unnecessary overkill because you may not know one-day either :). Could happen if you are really such a security minded person. And then what?

Say you already have an encrypted veracrypt volume/partition, etc. Adding a hidden volume requisite you create an outer volume in which to hide it. That means you must have several headers for  veracrypt to determine where each volume begins/ends;  no problem here since the wizard does the calculating for you but have your paper and pencil at hand. It becomes a juggling act remembering how big, where is what, which password to use, how many volumes did I create, etc..- when creating even multiple volumes in which you can create hidden volumes!!

Getting back to my scenario above... I would have two headers from which veracrypt can work with. It becomes even more complicated – in terms of security/secret – since each password muss be strong and unique! I can manage keeping 5 STRONG passwords/phrases in memory without writing them down but more than that requires physical notation because of their infrequent usage, and that becomes a security issue – where to store them. Albeit, the best passwords are the ones you can't remember - I am borderline!!

You didn’t mention how many inner volumes for each hidden veracrypt volume but more than one would set the stage for a chaotic scenario as mentioned - above. It would be like the concept of the Russian Matryoshka doll of nesting 7 in one. Adding the option of multi-inner hidden volumes (if at all practically possible) and you have utter chaos in the making!!

The challenge of already providing a user-friendly application and retaining the atrributes of confidentiality, integrity and availabilty would be totally thrown out of the window if such complexity was added to an already workable solution!!

Besides a hidden volume is a hidden volume without dressing veracrypt up like a Russian Matryoshka doll. Veracrypt allows that much TODAY and you have a better overview of what you may have just done.

And if you follow instructions carefully,  according to VeraCrypt,

  Even when the outer volume is mounted, it should be impossible to
  prove whether there is a hidden volume within it or not, your data should be well hidden.

That is my unprofessional thought on the matter.


Priority of GnuPG subkey selection during encryption I've got the following set of 6 subkeys

$ gpg -K
...
ssb>  rsa2048 2017-10-04 [E] [expires: 2027-10-02]
ssb>  rsa2048 2017-10-04 [S] [expires: 2027-10-02]
ssb>  rsa2048 2017-10-04 [A] [expires: 2027-10-02]
ssb>  rsa2048 2015-02-12 [E] [expires: 2025-01-05]
ssb>  rsa2048 2016-01-05 [A] [expires: 2026-01-02]
ssb>  rsa2048 2016-08-20 [S] [expires: 2026-08-18]

The context is that I bought a new smart card (Yubikey) and generated new subkeys for it. I wanted to keep record of old subkeys in my pubkey so that e.g. Github keeps displaying my old commits signed with old subkeys as "verified".

However I'd like to make sure that from now on only new subkeys are primarly used. e.g. If someone sends me an encrypted message I want them to use the new subkey.

I noticed gpg -e uses my new encryption subkey by default, so this works as intended, but my question is why?

In other words how does gpg determine which key to use during encryption? Is it based on order in which subkeys are saved in the file (as above) or creation/expiration date (newer has priority)?

GnuPG always selects the newest valid (sub)key for the respective operation (usually, the newest non-revoked key with a supported algorithm). Even if you select a specific subkey, GnuPG first resolves the associated primary key and then starts this selection process. To override this, postfix ! to a given key. This is something you might for example do in your git configuration if required.

I am not aware of any normative reference though (apart from the GnuPG code): neither RFC 4880 (OpenPGP) nor the GnuPG man page or manual seem to define the behavior. The relevant lines of code from the key comparison function:

if (old->validity == new->validity && uid_is_ok (&new->key, uid)
    && old->creation_time < new->creation_time)
  return -1;      /* Both keys are of the same validity, but the
                     NEW key is newer.  */


Exploit by overwriting relative address? I see a lot of exploits overwrite an absolute address to gain code execution. I wonder if there are vulnerabilities which offer the possibility to overwrite relative addresses.

Can you imagine a situation where is would be possible to overwrite a relative address?

Do you know any real world vulnerability where you can overwrite a relative address?

Thanks.

That would be much more difficult because you would need to use an offset each time. Various solutions exist, depending on which technique is used:

If ASLR is used, you don't know for sure where your shellcode is located, but you can still bypass this by spraying. Also only the base address is randomized, not the function offset, and you can return to plt.

nX/DEP also has it's flaws, for example Java requests memory by PAGE_EXECUTE_READWRITE and thus makes it executable.

But generally, for most known exploits to work, the address must be absolute. In a traditional buffer overflow on the stack, the shell code is part of the data which triggers the overflow, so it is in the buffer. The return address is absolute so it is not sufficient for the attacker to know the code of the attacked function; the attacker must also know what is the stack depth at that moment, and this depends on previous application behavior. Without the stack depth, you would have no clue how big the offset is.


When using PGP/GPG, is it safe to use the same public/private key pair on multiple computers for the same person? It seems somewhat unsafe to move the private portion of one's key around to multiple machines...but it also seems odd to have multiple identities floating around.

The private key is owned by a human, not by a machine -- indeed, the normal case is that you (as a user) have one key pair, and use the private key on all machines where you need to.

Having a key pair per machine would not work well; this would mean that when people send you an encrypted email, they will use one of your public keys, and you will be able to read the email only on the specific machine which contains the corresponding private key. This is hardly convenient.

We can say that as long as you want to read the same emails on several machines, then these machines must contain private keys which are functionally equivalent. Making these private keys distinct from each other is then a useless complication; just accept that you really want to have your private keys in several machines. Of course, the security of your key against theft will then be bounded by the security level of the weakest of these machines. You have to balance the convenience of being able to use many machines to read your emails, with the increased risks.

To move the private key safely (independently of the wisdom, or lack thereof, of having the same private key in many machines), you should protect your "keyring" with symmetric encryption and a passphrase of high entropy. Encryption of the keyring with a passphrase is the normal setting, so your job is "just" to use a strong passphrase. Since the format allows for reasonably strong password hashing (with iterations and salts), you can get away with a passphrase of entropy 60 bits or so. With such a strong passphrase, the keyring is "inherently" strong, and the travelling key is no longer an issue.


Usefulness of bcrypt(UUIDv4()) One of my colleagues is working on securing OAuth 2 client IDs and secrets for our OAuth server and he has come up with this scheme where he would not only use UUID v4 to generate random values, but also bcrypt them. Another colleague asked what's the purpose of bcrypt-ing them, to which he got the answer that just UUID v4 "loses 4 bits of randomness" (which would make the generated values more guessable).

The question seemed legit as far as my knowledge goes, but I couldn't find anything about the "loses 4 bits of randomness" part.

My question is if the usage of bcrypt here actually has an added benefit and, if so, how much added benefit.

I'm not very knowledgeable when it comes to cryptography, ciphers, crypto-secure random numbers and so on, so pointers to further reading related to this particular question would be appreciated.

UUID of type "v4" are supposed to be generated with 122 random bits:

o  Set all the other bits to randomly (or pseudo-randomly) chosen
   values.

However, it is not said that the said bits must come from a cryptographically secure PRNG (section 4.5 recommends it but does not mandates it).

IF the 122 bits indeed come from a secure PRNG, then they are immune to exhaustive search, because such a space is waaaaay too large for practical exploration (see this answer for more details). Adding bcrypt is thus just wasted CPU and gratuitous extra complexity, which is never a good thing, especially in security.

If the 122 bits are not produced by a secure PRNG, then you have a problem. It is conceivable that bcrypt might somewhat mitigate the issue, in the same way that bcrypt is good at tolerating passwords, which can only be described as "low entropy keys". But it really depends on how insecure the said PRNG is. A PRNG "security" relies on its unpredictability; here, "how much" the attacker does not know the 122 bits. If that "how much" is really low, then bcrypt won't save the day.

So my opinion is that when bcrypting an UUID is appropriate, then the UUID is not appropriate for use as a secret key, and you should fix that instead.

As for the "3 extra bits of randomness", this looks confusing, or confused, or both. I have no idea where that idea comes from.


Use RSA key to encrypt/decrypt personal document Suppose I have generated a public/private RSA4096 keypair using GPG. Is it secure to use this keypair to encrypt/decrypt documents solely for personal use, i.e., have an encrypted backup of some very important files of mine. In that case I'd be using something like:

gpg --encrypt --recipient "<my info>" a_document.pdf

# Then when I need to recover that document:
gpg --decrypt a_document.pdf.gpg

Is this a secure practice? Could an attacker recover the original PDF? As a separate note, if they also have the secret GPG key file (but obviously not the passphrase itself) would they be able to recover it?

Would it be better to encrypt using --symetric?

Until now I was thinking of this practice (encrypting files using public/private key pair) as perfectly secure (even when somebody has the private key but not the passphrase) but now I'm going through the Coursera Cryptography I course and one of the first points mentioned in the RSA cryptography is to never encrypt the message itself using RSA.

It depends on your use case.

From cryptanalysis point of view, symmetric is theoretically better as long as you have a really strong passphrase, because:

GPG encryption with RSA just encrypts the symmetric key which encrypts the actual file. So, there are two potential weak points instead of just one.
RSA and many asymmetric ciphers can be theoretically cracked by a quantum of computer with enough of memory. I am not aware of any quantum computer that can really do that today.

But most likely, those two threats are rather theoretical today. Unless the document needs to be kept secret for a very long time, I would not care too much about them.

From availability point of view, do you have a backup of your private key? If not, your backup with RSA might be useless. Imagine the storage (HDD/SSD) in your computer is gone. If you lose your private key, any backup encrypted by this private key is useless then. On the other hand, if you have your private key backed up, how secure is the backup of your private key.

From authenticity point of view: If you just encrypt your file by your public key, an attacker that can modify your storage can create a completely new document and encrypt it with your public key (unless you keep your public key private, which does not make much sense). That implies the file is not protected from modification this way. You would also need to sign it and then to verify the signature. I believe symmetric option handles this fully.

Note that secure passphrase matters a lot. An attacker can try to brute-force it offline and nothing but their budget and time restricts the number of attempts. This is not a PIN handled by a TPM or an online service that rescricts the number of attempts.


Periods in Common Platform Enumeration WFN (NIST Interagency Report 7695 ) I’m looking at NIST Interagency Report 7695 and the grammar described in 5.3.2  seems to say that all . need to be preceded by a \, but this doesn’t seem to be followed in the CPE dictionary. Am I reading something wrong?

The examples in that section include

  "9\.?"

  "8\.??"

  "*8\.??"

However, the CPE dictionary doesn't seem to conform to this. For example, cpe:2.3:a:sharp:rw-5100:1.1.0.0:::::windows_7:: has a version of 1.1.0.0 without a '\' preceding the '.'

Later on in the document in the following text

  In a formatted string binding, the alphanumeric characters plus hyphen (“-”), period (“.”) and underscore (“_”) appear unquoted.

So this does appear to conform to the specification.


Is client cert authentication with a 3rd party PKI cert any safer than using self-signed? I am working on a small M2M project (a few hundred nodes connected to a single cloud server), and want to use client certificate authentication, with each client getting its own unique cert at manufacture time. During development we have been using a self-signed .crt and .key to generate the client certificates, and all has been going well. We can issue and revoke certs as needed and our cloud service does the right thing with regard to refusing the connection if the client's cert is invalid or revoked.

Now we're getting closer to production time, and I wonder if this is a safe-enough approach, or whether there is some value in buying a PKI package from a "real" CA. The client nodes will be distributed around the world and will be connecting via regular Internet connections (no VPN, probably plenty of NAT'ted connections), if that makes any difference.

If you trust the security in place in the configuration of your own CA and you don't need other entities to trust you but only your nodes to trust each other, you're probably OK with your current setup.

If you want other entities to trust you, you should use a public CA or you could issue that third party a certificate such that they can trust your certificates. You could also exchange certificates and have mutual authentication whereby you trust each other.

If you don't trust your CA configuration, you should use a public CA. Note that a public CA will usually have a root HSM in offline mode which stores the root certificate and subordinate CA servers for different roles (issuing, revocation etc) and the audits and validation on these can be quite thorough.

I'm sure there are lots of other considerations but I'll leave that to those here who know better.


Server error when entering a percent symbol in search? Fuzzing a website and came across an odd behavior. The site has a search bar, it sends queries via a GET request with the standard ?q= parameter. When I try the standard XSS payloads such as <script>alert(1);</script> I get a 403 error.

When I type a percent symbol in the search bar it just sanitizes it to ?q=%25 however when I enter the percent sign in the URL directly it doesn't seem to sanitize it (e.g. ?q=%).

When I send this query to the server it responds with an error page saying Uh-oh! We've got a problem on our end. When I enter %00 directly in the URL it gives me a page back with a blank search term.

Any ideas on what's going on?

% in the URL is the start of a URL encoded character - see Wikipedia: Percent Encoding for details. If you just enter a single % it is an invalid encoding which might explain the error page you see. If you enter %00 it means a character byte 0 (i.e. \000, \0, \x00 for typical notations of this "character"). This gets likely interpreted/sanitized as an empty search term since it does not contain any actual printable characters.


Empty password field in /etc/passwd I am reversing a firmware update and found a empty password field in /etc/passwd

root::0:0:root:/:/bin/sh
otheruser:x:0:0:otheruser:/bin/false

Do I need a password to login as root?

I found out, that the x in the password field indicates that the hash is written in /etc/shadow, were a * indicates that the password is empty.
The /etc/shadow is not included in the firmware update, so i don't know the content.

An empty password field means the root account can be accessed without any password.

An * or ! means the account don't have a password and no password will access the account. An x means the password is on /etc/shadow.


Pre-hash password before applying bcrypt to avoid restricting password length Good practice is not to unnecessarily restrict password length, so that appropriately-long passphrases (perhaps 35-45 chars for 6/7 dicewords) can be used. (See e.g. Should I have a maximum password length? where a maximum of 1K is suggested, to protect against DoS without restricting users' ability to set long passwords.)

bcrypt is also commonly recommended (see e.g. Do any security experts recommend bcrypt for password storage?, http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html)

It is also recommended to use a salt (random, and stored with the password hash) -- I believe 32-bits (4 characters) is often recommended. (I understand the salt-size rationale to be "enough that the number of combinations is much bigger than the number of user records AND is enough to make rainbow tables infeasibly large" -- 16 bits is enough for the second part but may not be enough for the first.)

But AIUI bcrypt only hashes 55 bytes -- with 4 chars for the salt that leaves 51 for the password.

I'm guessing that we shouldn't just bcrypt(left(password,51)) and ignore the last characters.

Should we just limit users to 50 characters in their password (enough for nearly everyone, but not definitely enough)?

Should we use something like bcrypt(sha256(salt+password)) instead, and allow up to 1K characters? Or does the addition of the sha256 (or sha512?) step reduce the overall security somehow?

Do scrypt or PBKDF2 have similar length restrictions?

(The last question is just for interest, really -- I realise that the space-hardness/FPGA-resistance, and relative newness of scrypt, and the GPGPU-resistance of bcrypt compared with PBKDF2 are far more important considerations in deciding which hash to use.)

Using a secure hash function to preprocess the password is secure; it can be shown that if bcrypt(SHA-256(password)) is broken, then either the password was guessed, or some security characteristic of SHA-256 has been proven false. There is no need to fiddle with the salt at that level; just hash the password, then use bcrypt on the result (with the salt, as bcrypt mandates). SHA-256 is considered to be a secure hash function.

The point of a salt is to be unique -- as unique as possible, so that no two hashed passwords use the same salt value. 32 bits are a bit low for that; you should use a longer salt. If you have n bits of salt, then you will encounter collisions (two hashed passwords using the same salt) as soon as you have more than about 2n/2 hashed passwords -- that's about 65000 with n = 32, a not too high value. You'd better use 64 bits or more of salt (use 128 bits and you can cease to worry about it).


Code injection in .NET possible? I wonder whether code injection is possible for .NET-based web applications  as defined by OWASP. After performing some research on .NET and code injection there is something called code injection in the context of .NET (like this) but appears unrelated to code injection against web applications.

The default example for code injection (in accord to the OWASP definition) is against PHP applications, where code is dynamically created such that it depends on user input and then executed through eval(). Is there something alike for .NET?

The easiest way I can think to do code injection in .Net web application is to allow file uploads, and allow the user to upload a Razor template file (.cshtml or .vbhtml), and allow the user to request/execute it.

As mentioned in the comments, the System.Reflection is also very powerful, and could theoretically be used to inject code.


Considerations if I were to lengthen session expiration dates at some interval if the client stays active? Our API is protected with sessions that are stored and checked from the db (IE not signed JWTs from a client), and have an expiration stored in the db.

As of now it never updates the expiration, but I'd like for clients that ping the server at some interval to stay logged in.

I haven't heard of this so I just wanted to make sure I wasn't over looking some massive flaw.

So options.

Every time they hit an endpoint, bump up their expiration to say 1 hr from now. That's a bit excessive though.
To slow down the db updates, I could say that if they ping within 15 min. of expiry, I'll refresh it for another hour.
Something better?

Or are there any security holes I'm missing?

As we discussed in the comments, the biggest problem here is that if someone gets a session token, they simply can send periodic requests and keep the session running.

Also once a session has expired. Just mark it expired. Don't let a session renew on another ping. (I am assuming that these sessions are not like different users on same machine. In that case, it could also be the case that a user forgets to log out and another user logs in and gets access even after the session has expired)

You can refer the OWASP cheat sheet on ways to handle session expiration.


Some queries regarding SQL injection [I'm not really sure if I should be posting this on SO or here. I think my questions might be answered if I have had a good experience with MySQL. But, I don't. So probably, most of you will definitely want to tell me to read a good SQL book (if so, do tell me which books to read as the answer to my questions won't be directly answered in any book. So, I'd definitely want to read a book which answers such questions). However, currently I want to get my hands dirty with web app pen-testing and I can't do so without directly diving into it. Also, experience and knowledge comes with practice. :) So please bear with me.]

I am new to Web app pen-testing and am practicing SQL injection on Mutillidae. I'm at the user info login page and I gave the input as ' or 'a' = 'a. Worked. I got all the records from the database.

Now I want find out how many columns are there in the database and the column types (just for practice). I wanted to try out the "ORDER BY" method and the "UNION SELECT 1, null,null--" method metioned on the OWASP's testing for SQL injection web page. So I gave my input as ' or 'a' = 'a' ORDER BY 3-- (please note there is a space after --. I'm not sure how to put it in the pre-formatted text) as there were 3 fields returned in my previous attack. Worked again. So I played around with the query. I tried 1,2 instead of 3 in the 2nd query and they worked fine. The only change was that the order of the records returned were different. However the query also worked when I gave the input query as ' or 'a' = 'a' ORDER BY 4-- and ' or 'a' = 'a' ORDER BY 5--. However, I still see 3 fields in the output. Also, the query didn't work when I gave ' or 'a' = 'a' ORDER BY 6-- or any higher number than 6. Instead I got an error. My questions:

Why does the query work when I give 4 or 5 as the input? Does that mean there are 5 columns? If so, why do the output records contain only 3 fields?
Why does the query not work when I give any value >= 6?
I also noticed that the space is necessary after the --. If I don't give a space, the SQL injection won't work. Why do I need a space?
Why isn't a ; (semi-colon) necessary in my injected query. As far as I know MySQL, it doesn't execute the query unless I give it a semi-colon. However, my query executes here perfectly without a semi-colon. Why?

Why does the query work when I give 4 or 5 as the input? Does that mean there are 5 columns? If so, why do the output records contain only 3 fields?

Yes, the query would fail if you want to sort by a column which doesn’t exist. So as column position 5 works but 6 doesn’t, there are only 5 columns selected. Why only 3 of them are visible to the user is up to the developer. Maybe he/she selected all columns (e. g., *) instead of just the necessary ones or only the 3 are meant to be visible to the user.

  Why does the query not work when I give any value >= 6?

See above.

  I also noticed that the space is necessary after the --. If I don't give a space, the SQL injection won't work. Why do I need a space?

MySQL requires a whitespace or control character after -- as stated on Comment Syntax:

  In MySQL, the “-- ” (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on). This syntax differs slightly from standard SQL comment syntax, as discussed in Section 1.8.2.5, “'--' as the Start of a Comment”.

  Why isn't a ; (semi-colon) necessary in my injected query. As far as I know MySQL, it doesn't execute the query unless I give it a semi-colon. However, my query executes here perfectly without a semi-colon. Why?

The semicolon is only required as separator between statements. It is also used to terminate the statement input on the mysql console.


Need to trace the owner of a MAC-address connecting to my router I'm using a ISP with router of Linksys E900 model. During the last three month someone anonymous has been using my internet. I can see the MAC address using different IP address. Right now it needs to stop. How can I trace the customer and launch an complaint against them?

A simple solution if the MAC address is not being spoofed, add the MAC address to the Router's blacklist.

If it is being spoofed, then you should change the network name (SSID) on the router, change the password etc. and make the network hidden (e.g. turn off broadcast SSID).

Once it is hidden you would need to be able to connect to it by entering it manually in your wifi setup.


My router is getting port scan attacks My internet suddenly cut out yesterday, i checked the router and it looked like nothing is wrong. I looked at the logs and i see this

2019-08-18 12:50:39 Security    Warning Detect UDP port scan attack, scan packet from 212.2.127.253
2019-08-18 12:43:19 Security    Warning Detect UDP port scan attack, scan packet from 212.2.96.53
2019-08-18 03:59:04 Security    Warning Detect UDP port scan attack, scan packet from 212.2.96.53
2019-08-17 19:08:37 Security    Warning Detect UDP port scan attack, scan packet from 212.2.96.53

When every attack happens my internet cuts out so how do i stop it?

You should definitely contact your ISP about this and let them know as this is something they should block.

Some ISP's renew the IP of the subscriber every time the router/modem resets, I recommend you try this too.


Insert string to memory with null character I'm trying to implement return-to-libc,
here's the code

void func(const char *str) {
    char buf[4];
    strcpy(buf,str);
    printf("you entered [%s]\n",buf);
}

int main(int argc, char *argv[]) {
    if(argc != 2) {
        printf("Need an argument\n");
        return 0;
    }
    func(argv[1]);
    return 0;
}

Now the problem is, the address of the system function that my pc gives me is of 6 hex digits instead of 8 hex digits (which means the front two digits are zeros), but I use strcpy to copy the string, which terminates copying the string as soon as it encounters null character.

Any ideas how to copy the whole string I pass including the null character ?
Or anything that you feel will help me with this, is appreciated.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void func(const char *str) {
    char buf[4];
    strcpy(buf,str);
    printf("you entered [%s]\n",buf);
}

int main(int argc, char *argv[]) {
    if(argc != 2) {
        printf("Need an argument\n");
        return 0;
    }
    func(argv[1]);
    return 0;
}

I compiled your code with the following command.

gcc blah.c -o blah

Cracked open gdb.

[ayrx@localhost ~]$ gdb -q blah
Reading symbols from /home/ayrx/blah...(no debugging symbols found)...done.
(gdb) run AAAAAAAAAAAAAAAABBBB
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/fedora/blah AAAAAAAAAAAAAAAABBBB
you entered [AAAAAAAAAAAAAAAABBBB]

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()

Here is the register dump from gdb.

(gdb) info registers
eax            0x23 35
ecx            0x7fffffde   2147483614
edx            0x0  0
ebx            0x4e735000   1316179968
esp            0xbffff160   0xbffff160
ebp            0x41414141   0x41414141
esi            0x0  0
edi            0x0  0
eip            0x42424242   0x42424242
eflags         0x10286  [ PF SF IF RF ]
cs             0x73         115
ss             0x7b         123
ds             0x7b         123
es             0x7b         123
fs             0x0          0
gs             0x33         51

As you can see, the eip register has been overwritten with the last 4 Bs from my input.

The final step will be to overwrite the eip register to point to the location of your shellcode. Since your buffer is small, you will have to find some other memory location to stash the shellcode. Overwrite the eip register to point to that location and you have won. I'll leave that part to you.


Meaning of ssl-cert section in nmap output I am trying to learn the basics about security so I started by scanning the IP of a friend using Nmap, I have some questions about this section:

PORT     STATE SERVICE    VERSION
3389/tcp open  tcpwrapped
| ssl-cert: Subject: commonName=Ventas-gp-1
| Issuer: commonName=Ventas-gp-1
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2016-09-25T12:11:37
| Not valid after:  2017-03-27T12:11:37
| MD5:   95cf e484 a18f 98d1 49f1 186b 45ad ee62
|_SHA-1: 53c8 b5f3 4424 0863 7d2e 42e3 f09c 3148 1c1d dafa
|_ssl-date: 2017-02-17T12:41:06+00:00; +2m26s from scanner

This is obviously about a Remote Desktop, but with all the information about encryption, could this be used to crack the windows password? passing this data to "John the ripper" for example

Also in this network there is a Voip phone, this phone is in the DMZ of the router and also in the router the TCP 5060 is open, but none of this are shown in my nmap output, I want to know why?
I am using: -T4 -A -v

What you have there is information about an SSL certificate. The certificate identifies a computer, or more precisely a service running on a computer. The numbers after “MD5” and “SHA-1” are “fingerprints” of the certificate: the computer says that it can prove that it knows some secret value which is associated with these fingerprints. (MD5 has known attacks and SHA-1 is deprecated though; today SHA-256 or SHA-512 should be used for this purpose.) There is no way to obtain the secret values from those fingerprints — they're hashes of a public key, and the computer knows the corresponding private key. If you want to understand more about how this works, see How does SSL/TLS work?

The information you have here identify a service running on a computer (e.g. the RDP service). They do not identify a particular user of that computer. They have nothing to do whatsoever with any user's password or with any way in which a remote party could gain access to that computer. The information here is how another computer trying to talk to this computer can know that it's talking to the right computer.

Despite the appearance of sha1WithRSAEncryption, the information here is related to signatures (roughly speaking, how this computer can sign “yes, I am me”), not to encryption. The word “encryption” here relates to what happens during the TLS protocol, but not to the part where the certificate is directly relevant.


Any campus email systems automatically testing links? I heard that there are some university campus email systems that "click" all the links on incoming emails and thus inadvertently unsubscribe recipients from email distribution lists if the email contains a one-click unsubscribe link. Does this exist? Has anyone had first-hand experience with this from either sender, campus IT or recipient end? Is it then possible to get whitelisted by such systems?

I'm having a hard time believing this exists. It would overturn the wishes of all the recipients who willingly subscribed. Are there any negative security implications in doing this?

In theory this should not happen.

But for short periods I can see it happening, in certain not carefully tested systems.

The http standard includes the following actions, HEAD, GET, POST, DELETE and a url can use any of these.

The default GET is what we are talking about here, and GET requests should not actually action anything. Theory being a GET should retrieve the resource, not changing it in the process.

Of course this is not in practice followed, such as these common unsubscribe links.

So in practice urls should not be retrieved by GET without user action except in certain exceptional cases.

Even using the HEAD action may impose security concerns such as unequivocally identifying a valid email address.

Example

Google had a pre-caching service at one point (VPN or Browser or something) that prerequested website urls to improve performance/bandwidth.
This caused certain web-apps to malfunction in similar ways to the Question.

For instance I developed a web-app around 2000 that used GET urls to do actions such as delete record an so forth, not a mistake I would repeat of course.

This pre-caching service looked at the urls and web site and inferred that it should NOT pre-cache certain links using a heuristic with inputs such as is this an authenticated site, is it https, is the url containing the string DELETE or UPDATE etc or identifying the web framework used for the site.

I dont know how accurate the heuristic was, I heard of some issues raised in this system but I dont know the detail.

Because this is a easy mistake to make on any web site (beware web coders) be very careful of implementing this feature.


Does this evidence seem consistent with an intrusion via the VNC server? I am new to this forum, so apologies in advance if this question does not seem to fall within its scope, or if it seems too long:

On two occasions over the past ~3 weeks, a hacker gained remote access to my laptop (PC running Windows 10), as evidenced by mouse cursor movement.  On both occasions, I was connected to the WiFi network at my university, and rapidly shut down the computer as soon as I saw what was going on.

On the first occasion, I was in denial, assuming that the cursor movement was due to a touchpad malfunction. The second time, the cursor movement looked very purposeful and human-like; I am confident that my computer was remotely accessed.

Since then, I have only used this laptop offline.  I am preparing to do a clean install of the OS.  Before that point, however, I'm trying to find any evidence that confirms my initial suspicion that my computer was accessed through the RealVNC Server that I did have running on there.  This assumes that someone was able to identify my password through brute force.

Tricky thing is, I'm lacking in evidence that this was the means of access.  Usually, VNC Server connections should prompt an on-screen notification, which I never saw.  I also cannot find evidence of VNC connections if I search the Event Log for the dates/times when I noticed the cursor movement.  So, now I'm wondering if (a) the hacker suppressed the logging/notification, or (b) my laptop was accessed in some other way.

There are three other pieces of information that might be useful:

(1) If I look in the Event Log at the date/time of the first incident, I can find a Logon of Type 3, with Security ID "ANONYMOUS LOGIN", Security ID "NULL SID", a Login Process of "NtLmSsp",  and blanks or 0's in any fields that would provide information about the origin (no Workstation Name, no IP address, etc).  Is this consistent with a web-based VNC login, or something else?

(2) In both cases I noticed the cursor movement when I was using Chrome.  Maybe just a coincidence.

(3) I have run full scans with both Symantec and MalwareBytes; neither detected anything.

It seems that understanding the cause of these incidents will be important for preventing them from happening again.  As stated above, I plan to reinstall the OS, and since I have no future need for VNC Server, I will not reinstall it.  I've also been changing the relevant passwords.  But I'm not sure if that will be enough.

Thank you in advance for your time.

Looks like someone is trying to bruteforce your Windows' credentials, as of NtlmSsp event suggests it. I don't think this is related to VNCServer, unless you configured it to login with your Windows' credentials.

Before anything else, as we don't know if you've been RATed or not, you should monitor any Internet connection made on your computer (with no connectivity). As you're using Windows, this can be made using netstat (CLI) or SysInternal's TCPView (GUI). Check for any connection on unusual port made by any processes, as a tool can easily be injected in e.g. explorer.exe. If there is any suspicion of unwanted connections, try to remove infection yourself, using Malwarebytes or, as a workaround, SysInternal's Autoruns. Don't use Symantec Norton Antivirus as it is not very efficient and buggy.

If there is nothing, what I'd do next, before reinstalling your Windows, is to connect to your University's WiFi, disable VNC, and check for more events like the one you described.

To do this, launch a monitoring tool like Cyberarms IDDS (free and open-source) to check any attempt of intrusion. It'll then show you the IP address and you will be able to report it to your University's Network Administrator, and block it using the IDDS or your FireWall.


General techniques for identifying an unknown service I have a specific sample I'd like feedback on, but my view is an answer about general techniques is more valuable for this site. I'll leave the details in, in case anyone googling this bumped into the same service.

My questions:

What are general techniques and resources for identifying an unknown service, or something on a non-standard port that isn't being talkative?
Does the behaviour below ring a bell with anyone? (Are there steps I have missed to further identify the service?)

–

While on an engagement, we have encountered an open port, 10001.
As you might've guessed, as far as I can tell it does not respond to  protocols usually used on that port. My search has not been completely exhaustive but I have fuzzed the first three bytes and found a response for the first byte.

Observations on my specific unknown service:

Speaks TCP
When sent a capital i,  I\n,  it responds I211568 \x00 \x00
Messages seem to be null- and newline-terminated; anything but those after the capital i do not affect the behaviour, but a null before it will impair the response.
nmap shows it as scp-config, once as tcpwrapped

EDIT:

Turns out it was the Remote Port of a Swann DVR

I think what you're asking (in hindsight) is Port Independent Protocol Identification (PIPI), a method for detecting well-known (published as RFC) application layer protocol or dark-protocol (such as malware, covert backdoor etc.) being serviced on a non-standard port. Indeed, that's what researchers of protocol obfuscation, malware (and anti-malware) developers and IDS/IPS teams ponder on all the time. The goal in part is to identify the application without relying on the layer-4 port numbers. There are two techniques widely used in IDS,

Statistical analysis of the traffic within a connection
Locating protocol-specific byte patterns in the connection's payload

Do read this white paper  for full explanation.

In your particular case you could,

Customize nmap-services-probes file to add a new service signature based on the observations from your specific unknown service.
Consider writing a Wireshark dissector once you gathered enough reliable details about the protocol behavior such as packet size, communication pattern, idiosyncrasies in the payload and the like.


How does IP whitelisting help secure an API? I'm trying to get a better understanding of the extent that IP whitelisting helps to prevent attacks against an API.

At the moment I'm thinking of a B2B scenario where organisation A provides an API and organisation B consumes the API.

If the organisation A that is producing the API configures its API so that it will only accept IP addresses from organisation B, what additional security does it provide?

Note, this is inaction (OP: "in addition"?) to other security measures such as Shared secret + TLS or Mutual TLS.

I understand that it will have some effect on a denial of service attack and can (OP: finish this sentence?)

[how does] IP whitelisting help to prevent attacks against an API[?]

Simply by limiting the set of IP address that can submit requests to the API to a smaller number of presumably trusted addresses.

If you have 15 customers with one IP whitelisted to use your system, then that is far less of a threat than the 3 Billion addresses across the Internet.
If they are your customers, they are in a relationship with you, and presumably have less interest in attacking you because a) you know who they are, and b) if they break you they lose whatever service you're providing them.

It's still not a perfect control:

Your customers may have dynamic IPs, and be poor candidates for whitelisting.
Your customers may get compromised, and used as a platform for attacks by a malicious third party.
Your customers may misconfigure their systems to forward traffic from any system on the Internet to yours, negating the whitelist (yes, I have seen this exact thing happen).
A malicious attacker could sign up and get whitelisted solely for the purpose of enabling an attack against you.

But it does cut down on the casual attacks that every system on the Internet is constantly receiving.


Account-lock security policy (username/password) I am currently working on an application with regard to applying a security policy to the application. We are locking the account after X failed login attempts in Y minute. The account will be locked for Z minutes. I want to know whether the account should be locked if there are successive failed login attempts or that the account should be locked if there are failed attempts within the past Y minutes.

Example: failed login attempts = 3 within 10 mins

If the user enters the wrong username/password 2 times. Then logs in successfully the 3rd time. He then logs out and attempts a failed login.(All the attempts are within the 10 minutes.)

Should the account be locked or not?

There is no right or wrong answer. The more aggressive lockout policy is slightly more secure, and slightly less convenient for your users. You have to assess if it is worth doing based on your application's requirements, your knowledge of your user base, the value of the asset you are protecting, your threat model, etc. etc.


Difference between .pfx and .cert certificates What is the difference between .pfx and .cert certificate files?

Do we distribute .pfx or .cert for client authentication?

There are two objects: the private key, which is what the server owns, keeps secret, and uses to receive new SSL connections; and the public key which is mathematically linked to the private key, and made "public": it is sent to every client as part of the initial steps of the connection.

The certificate is, nominally, a container for the public key. It includes the public key, the server name, some extra information about the server, and a signature computed by a certification authority (CA). When the server sends its public key to a client, it actually sends its certificate, with a few other certificates (the certificate which contains the public key of the CA which signed its certificate, and the certificate for the CA which signed the CA's certificate, and so on). Certificates are intrinsically public objects.

Some people use the term "certificate" to designate both the certificate and the private key; this is a common source of confusion. I personally stick to the strict definition for which the certificate is the signed container for the public key only.

A .pfx file is a PKCS#12 archive: a bag which can contain a lot of objects with optional password protection; but, usually, a PKCS#12 archive contains a certificate (possibly with its assorted set of CA certificates) and the corresponding private key.

On the other hand, a .cert (or .cer or .crt) file usually contains a single certificate, alone and without any wrapping (no private key, no password protection, just the certificate).


How can a critical Adobe Acrobat security update, only available as an unsigned executable over plain HTTP, be verified? A critical security update for Adobe Acrobat Pro and Standard 9 on Mac OSX is only available over HTTP, and is unsigned code. Is there any out-of-band way to verify the download is authentically from Adobe?

You're right. If you go to Adobe's website the update is transferred over HTTP and not HTTPS, which give any hacker in the network to hijack your update file with a simple Man In The Middle Attack and inject his/her malicious file instead of the legitimate Adobe's update.

However if you go to the same page and instead of clicking the download now button you copy the link and add HTTPS as a prefix to it. The file will transferred securely over HTTPS.

here is the direct link: https://ardownload.adobe.com/pub/adobe/reader/mac/11.x/11.0.06/misc/AdbeRdrUpd11006.dmg


Can my company view my PAST browsing history of what I've done at home with *my personal* computer and *my personal* network? This is if I later on connect my personal computer to the company network?

I don't browse anything non-work related using the computer network on my personal computer at work, and I am aware that they can see what I have browsed while I am on their network even though it is with my own computer.

No. Your history is not actively communicating for anything to be seen - hence the name "history".  If this were a work computer, it would potentially be a different answer because they could have logging or monitoring software to track its activity and upload the "history" as soon as you connected it back to the office network.  Since this is your personal computer, unless you allowed them to install some kind of logging or monitoring software, there's nothing for them to be able to see because they have no way to access your system.


How Vulnerable Is An Older Version Of Outlook As An Email Application? I am significantly displeased with some of the newer versions of Microsoft Outlook. I would prefer to continue using my older version from Office 2000 (on Windows 7 using workarounds). As a networked application which is no longer being updated by Microsoft, is it critical to update this application to the latest version of Outlook 2016?

I am curious because I intend to continue using the rest of Office 2000 (Word, Excel, etc.) alongside firewall rules which prevent internet access. (If you think this is also a bad idea, please detail why). Obviously, Outlook will have to communicate over Port 25 to the mail server, what kind of threats will I face from unknown senders that won't be a problem in Outlook 2016... most email security seems to center on safe reading habits. However, I have looked through some Outlook CVE's and its quite clear there are numerous exploits which "could allow a remote attacker to run arbitrary code..." on both older versions and new.

What kind of threats will I face from unknown senders that won't be a problem in Outlook 2016

Outlook 2000 is vulnerable to known attacks, but the key difference compared to 2016 is that there is no effort from Microsoft to close the Outlook 2000 vulnerabilities. Any bugs that are found now that support is dropped, will not be patched, so there can only become more known vulnerabilities as time passes.

  Most email security seems to center on safe reading habits.

Take CVE-2006-1305. The attack was conducted with malformed email headers. This attack would trigger when the message is downloaded from the server, and thus be underway before you decide to open the message or not.

  I intend to continue using the rest of Office 2000 (Word, Excel, etc.) alongside firewall rules which prevent internet access.

While your firewall might stop the applications themselves from contacting the internet, there is nothing stopping an attack from using a different program to connect to the internet. A macro included in a document might instruct information to be copied to a shared folder on disk, or it could open some other program, for example a spyware application.

In short, running unpatched and unsupported software is a very bad idea, and should be avoided as long as the system is connected to the internet.


how strong is AES without salt The AES cryto library provided to us from company, does not generate a different encrypted value for plain text.

If text is "abcd" , it will generate the same encrypted value over multiple iterations.

So when we have to interact with other applications ( they redirecting it to our website and we redirecting back to their website), the scheme we use is to add a timestamp with a "#", and then encrypt.

Like in this case text becomes "abcd#32342534234232" , and then we encrypt it. The caller application decrypts it and discards the timestamp part.

I want to know the pros and cons of this scheme considering "abcd" is a user data but not a critical data like password.

Thanks !

Block Ciphers never incorporate a salt,  this is usually used for hash functions.  Block Ciphers like AES will use an Initialization Vector to ensure that two identical plaintext inputs will not produce the same cipher text output.

Also note that mode of operation that you choose for your block cipher is very important.  Not all modes use an IV,  for example ECB mode doesn't use an IV.  ECB mode can be unsafe for multi-block data, here is an image encrypted with ECB mode:

Related:
Why is using a Non-Random IV with CBC Mode a vulnerability?


Why is BlueCoat proxy passing HTTPS communication to Google sites? I have a machine behind corporate BlueCoat's proxy server. For any HTTPS site I get a certificate signed by BlueCoat's CA, for example:

BlueCoat
  *.duckduckgo.com

The only exceptions are sites owned by Google for which I get the proper certificate for google.com and most of its SANs (youtube.com goes unaffected, android.com gets intercepted):

GeoTrust Global CA
  Google Internet Authority G2
    *.google.com
      expires on 2016-08-17
      fingerprint 66:05:80:34:2A:DC:33:B8:92:78:5D:2C:F9:C9:69:F6:19:81:4A:35:DB:FF:19:89:3B:FA:5F:6B:33:37:58:FD

I get the same results for browsers using Microsoft and Mozilla certificate stores (although that shouldn't matter).

I doubt proxy administrator deliberately added an exception for Google domains, but I cannot exclude that (and I have no means of confirming).

Is there any other explanation for bypassing the BlueCoat proxy when accessing Google sites? Or a way to figure it out?

Certificate pinning shouldn't have anything to do with it (and all other sites like twitter.com come with a BlueCoat-signed certificates).

My guess is that your proxy administrator has turned off ssl-inspection for google domains because of an update of Chrome, and what ciphersuites it will attempt to use for google domains.

https://forums.bluecoat.com/forum/security-policy-enforcement-center/proxysg/37493-proxysg-is-offering-unknown-elliptic-curves-chrome-google-connect-failure

Unfortunately, bluecoat does not currently support the ciphers requested by Google Chrome, and the SSL connections fails.

One workaround, is to whitelist google sites from SSL-inspections - which in my opinion is bad. The other would be to turn off support for the new EC ciphers in Google Chrome.

This problem only affects Chrome - not other browsers.


How is this SSL spoofing possible? Here is a description of a seemingly successful SSL certificate spoof:

https://cryptostorm.org/viewtopic.php?f=67&t=8713

  The session is initiated by pointing a newly-opened icedove window
  manually at the following URL:

  CODE: SELECT ALL https://google.com

  This URL then redirects to the local google subsidiary for the
  exitnode cluster in question (Paris, France):

  CODE: SELECT ALL

  https:// google.fr

  Immediately we notice that icedove is not happy with the certificate
  credentials... although the page still loads without any errors or
  overt warnings:

How is this possible? Why would browser not issue a security warning in this case, since the certificates are not trusted by any root certification authority it has locally in its cacerts?

The authors of the page you are referring to fail to understand some basic concepts and make otherwise false statements. Because of that I don't think that you should take any statements or conclusions from this article for real.  Some examples:

  This certificate identifies itself (via CN field) as *.google.com despite being served during a putative session with google.fr (again, this kind of obvious certificate misconfiguration is all but impossible to imagine google doing in production systems):

While the certificate they cite has *.google.com as the CN as they correctly state they fail to recognize that the certificate contains *.google.fr in the subject alternative names (SAN) section. And obviously the authors don't know that if this section is present and contains DNS names like in this case then the browsers should not even look at the CN but only at the SAN. This means the certificate is matching the server and the trust chain is also correct, so it is no wonder that the browser does not complain about it.

  However, it's notable that the connection does not appear to represent an EV-class certificate. In other words, there's no 'green lock' as we see in any of google's other services. For example: ...

I don't know which "other services" they refer too but neither google.com nor youtube.com use EV certificates.

In summary: There are several obvious errors in this article. Therefore I recommend to simply ignore any statements and conclusions made in this article because the authors don't seem to understand what they are talking about.

Edit: I just found that this article is also heavily critized at https://news.ycombinator.com/item?id=10030820


Can CVEs (or any vulnerability) be dependent on one another? I am collecting a bunch of CVE data for some security-related analysis and wanted to know if there are examples of vulnerabilities that depend on the existence of another vulnerability on the same system. A sort of vulnerability-dependency, if you will.

For example, let's say that a system is vulnerable to CVE-1, and later another vulnerability (CVE-2) is discovered that is only exploitable if the system is still vulnerable to CVE-1. Is there an example of such a vulnerability?

Or would the original CVE just be updated with the new information?

A CVE is a vulnerability description, ie. a document stating that some security property has been found to be broken.

As explained in Ohnana's comment, a CVE might indeed state that to be exploitable some other security properties not part of this CVE should also be broken (typically CVE requiring a specific access from the attacker, whether it is local, privileged, in position to tamper network traffic, etc.).

However the CVE will not limit this to the use of another specific CVE. It will not tell for instance that this CVE is exploitable if a local access has been gained by using specifically this other CVE. It will just say that this CVE is only exploitable with a local access.

However, while there is not strict dependency between CVEs, there can still be a kind of link between them because, when an important enough (or suspected to be important) vulnerability is discovered in some widespread software, a lot of security researchers will dig into this and possibly make other discoveries.

Then, it will be up to determine how such discoveries should be classified:

In the scheme you describe, which I understand as "using this vulnerability allows the attacker to do even more harm as previously expected by proceeding in a certain way", this will most likely ends-up as an update of the first CVE. It means that the vulnerability's impact seems to have been underestimated and needs to be revised.
However, most often such discoveries are independent vulnerabilities. Each of them will get its own CVE and can be exploited independently. However it is possible that the same fix can solve several of such CVEs since they are likely to concern the same part of the software (the one under scrutiny by all security researchers). This is useful because it will help to increase the fix quality. Shellshock with its list of CVEs published after the first discovery seems a good example.
At last it is also possible that several discovered issues, while being independent from each other and not necessarily being all security issues (and therefore not needing a distinct CVE), may combine to increase the initial CVE threat. For instance, CVE-2015-3456 mentions a vulnerability affecting Qemu's Floppy Disk Controller in some versions of Xen and KVM and allowing to escape the VM; while this issue should be restricted to environment having floppy drive emulation enabled, researchers have discovered that "if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers".