How does one properly assess risk? Security is never 100%. There is a need to balance risk and cost. Risk assessments need to be performed to determine the cost-effectiveness of preventive measures.

There are a few questions I would like answered:

What are the frameworks to follow when performing risk assessment?
How does an organisation effectively model a threat?
How does an organisation accurately determine the monetary cost of a potential security threat specific to their own current circumstances?

I don't think there are any questions here that covers this yet.

Please - no answers consisting of only links to outside resources. I would like one or two detailed answers covering an overview of how risk assessment is usually done in large organisations.

ISO/IEC 27005:2011 is the ISO standard providing guidelines for risk management and contains a lot of advice for the assessment part of that process. A ridiculously abbreviated summary might be:

Identify the risk by:

identifying your assets
identifying the threats to each asset
identifying the existing controls protecting each asset
identifying the vulnerabilites in each asset that the threats might exploit
identifying the consequences of harm to each asset

Analyse the risks by:

determining likelihood of harm (i.e. loss of Confidentiality, Integrity, or Availability)
determining the impact of harm
combining those values to assign a level of risk

Evaluate the risk by comparing the level to your acceptable risk threshold

You would usually do the identification step by taking inventory of your assets and interviewing their owners and maintainers about them.

The analysis stage is usually qualitative and fairly simple. For example, you might assign values of Low, Medium, or High to both likelihood and impact of each risk, then have a simple table showing the consequent risk value. High likelihood and high impact means a high risk, and so on. This seems rather simplistic, but it's very hard to give precise quantitative values to likelihood and impact across all your risks. What's the likelihood that my office will burn down next week? Spock might estimate the probability as 2.457% but I'm human, so the best I can do is estimate it is "Very Low". Your circumstances may be different, of course.

Finally the evaluation stage is simply comparing the level of risk to what you find acceptable, to see if the risk needs treatment. Again, it's a little simplistic, but the reason you're doing analysis is to determine a) what risks you need to treat and b) what order to do them in.


Does adding a non-entropic part to a password makes it less secure? Suppose I'm encrypting a file via AES using a password of my choice, or creating a TrueCrypt volume using a password and no keyfiles. Which of the following two passwords would be more secure:

nf890y9jqb

nf890y9jqb123456

The first one has a set of characters chosen at random, whereas the second one has the same characters but with an extra set of non-entropic characters added at the end. Does the extra length make it more secure, or the non-entropic part actually makes the file easier to decrypt, thus lowering security?

No, longer is not stronger.

What makes a password strong is its entropy: how much unknown the password is to the attacker. Adding a "non-entropic" suffix to the password does not add to the entropy (by definition) so it does not increase the hardness of the task for the attacker. It does increase the hardness for the normal user, though, since that means more keys to type in.

Adding a known suffix or prefix does not lower security either, except in the indirect effect of encouraging the user to choose a less entropic password to make his job easier. Unless the password processing makes something dumb, of course. For instance, suppose that passwords are truncated to their first eight characters (typical of old DES-based Unix crypt()) and that you add a fixed 6-letter prefix to your password, turning "o7843vD!" into "123456o7": in that case, the prefix makes the attack much easier.


Is it possible to bypass 2FA and access bank account in this system? Nowadays, any credit/debit card transaction made online (at least for mine) requires one to enter the card details (Account No., Expiry Date, CVV etc). In the end, a OTP (One Time Pass) is sent to the mobile number linked to that Credit/Debit card for 2-Factor Authentication.

In this process, if someone (other then the owner) possesses the correct Card No. and CVV of the card, can he gain access to the account and make any transactions?

This assumption is made while keeping in mind that the device on which the OTP is being sent is not compromised.

It seems like this method of authentication is not that predominant. If one has to pay a sum of 100$ via his account, the person goes through this process:

Enter the Credit/Debit Card number, enter the Expiry date of the card and the CVV (a 3 digit code)
For Complete Authentication of the User, an OTP is sent to the mobile number registered to that account.
Now the user has to enter the OTP (this is the final step)
If all the aforementioned details are valid, the transaction is made.

Certain things to keep in mind:

I get redirected to the bank account's site when i have to enter the OTP. i.e. The OTP isn't entered at the merchant store, rather it is entered at the bank site, which the merchant redirects us to
If the entered OTP is wrong, the site provides an option for resending a new OTP to the same number
OTP is 6 digits

Your experiences are in no way universal. It's possible that many banks in your country do authentication that way, but it's not the case in the USA. Your question title makes it sound like you're talking about online banking (which usually just uses conventional username+password credentials, with sometimes the option of a second factor, once you're past account creation), but I assume you actually mean "Is it possible to pay with a card online without an OTP"?

In a strict sense, the answer is obviously yes; I can both sign into at least one of my banks or pay from several of my cards (though my usual one notifies me about certain payments) without any kind of OTP being involved at any step.

With all that said, let's look at the actual situation of your bank, and its 2FA implementation. There's a few things that need to be confirmed:

Is the OTP generated securely (that is, not predictable in any way)?
Is the OTP long enough that you can't just guess a bunch of times and brute-force it?
Does the OTP have brute-forcing protection, so you can't just set a script to trying for a day and get it anyhow?

Beyond ways that an attacker might bypass the OTP, they could also just get it sent to them. Phone numbers in general are not good for 2FA; it's too easy to maliciously port somebody's number (the carriers don't care). That's assuming you can't just steal the device and see the OTP above the lock screen (if a lock code is even set) or, if necessary, remove the SIM and put it in your own device. TOTP apps (such as Google Authenticator) plus a lock code, or a hardware token (such as a Yubikey) are much more secure.

Finally, consider that the system you described isn't actually two-factor authentication. Both factors are conventionally going to be a "thing you have", and while they're different things, they're both commonly carried in a purse or pocket, and sometimes are carried together (phone cases that also have slots for payment cards are somewhat popular around here). Yes, the phone might not be usable without its lock code or SIM security code (either of which are a "thing you know"), and the payment card details could be memorized rather than carrying the card (turning it into a "thing you know"), but the scheme overall still doesn't really fit the strict definition of 2FA.


How to sniff Bluetooth traffic using Android? I have two Arduinos using Bluetooth to communicate one with another. Is it possible to sniff the Bluetooth conversation between the two devices?

An Android solution would be great, I heard of hcidump but I think that sniffs only the connection between the phone and a device.

If with Android is not possible alternatives are welcome.

I'm not aware of something that would turn your Android bluetooth radio into a sniffer. I think you would need to invest in an Ubertooth to accomplish what you're looking for.

http://ubertooth.sourceforge.net/
http://hakshop.myshopify.com/products/ubertooth-one

With the ubertooth you'll be able to sniff the bluetooth packets between your arduino devices.


One Time Passwords. Using OTP at Windows, Ubuntu and internet sites Is there a way (software, hardware/token or web-ware) to use One Time Passwords in the following scenarios:

Logon to my pc/laptop (windows or ubuntu)
Logon to sites with OTP (without having out-of-the-box support for OTP, which AFAIK none of them have).

Do you use any OTP solution? Experiences so far?
I'm interested in both freeware/opensource and commercial (paid) solutions.

OPIE Authentication System ("One time Passwords In Everything") works on most any BSD/Linux/Unix system - e.g. opie-server and opie-client packages under Ubuntu.  It can be used e.g. in PAM authentication or for web servers.  There are clients (at least) for Windows and MacOS also.

If a site is a "relying party" for some sort of federated authentication (e.g. OAuth, OpenID, Shibboleth, SAML) you can use OTP once to log in to an identity provider that supports it, and use what are essentially one-time credentials from them to log in to the site.


Is using a third party browser in iOS more secure than Safari? I have read that many iOS exploits target the Safari browser. Would using another browser on my iOS device be safer?  Does Safari being a system app give it more access to the OS than a third party browser that I install through the App Store?

Basically not, since all 3rd party browsers on iOS use the webkit engine.

A simple way to demonstrate that is with CSS stylesheets, any browser specific attributes such as -moz won't be rendered on the Firefox iOs app. Only the non vendor-specific css or webkit attributes.

Therefore all potential vulnerabilities webkit has, apply to all browsers inside the iOs ecosystem.


How much more difficult does it become to crack a password when appending a 5-digit pin? I have a quick question regarding password cracking.

Lets say you append a 5 digit pin on the end of your password. An example would be instead of a password of "password" it would be "password12345".

So when trying to crack the password using bruteforce or a dictionary you would have to append every possible pin combination on the end for every single attempt.

So in reality how much more difficult would that make it? I'm guessing not much.

A 5 digit decimal number has 100,000 possible states, so it increases the time to crack by factor 100,000.

This assumes that the cracker expects you use a common word plus a 5-digit number.


What is the difference between Ghidra and Ida? Is there a comparison between Ghidra and Ida? Are there any specific features and functionality that Ghidra while Ida doesn't? Is there a good source (most preferably book) that explain Ghidra in detail?

This is largely subjective, but:

Ghidra is free and open-source on GitHub, including the decompiler. IDA is very expensive, particularly when you start adding the decompiler licenses.
IDA supports some architectures that Ghidra doesn't, and vice versa.
IDA has a debugger whereas Ghidra does not.
Ghidra has the ability to load multiple binaries at once into a project, whereas IDA support for this is limited and mostly an ugly hack. This means that you can trace code between an application and its libraries more easily.
Ghidra's disassembler has data flow analysis built in, showing you where data can come from when you click a register or variable. IDA has "dumb" text highlighting to show other uses of that register. These features are slightly different implementations of the same concept and both have their uses.
Ghidra has collaborative disassembly/decompiler projects built in by design, whereas IDA requires plugins to do collaboration and the IDA database files are not designed to be shared.
Ghidra has an undo button! And it works! (IDA doesn't and it's super annoying)
IDA is way more mature and has a lot of little features that have been added over the years that Ghidra cannot (yet) mirror.
Since IDA is a more mature and ubiquitous product, there are a lot of open-source tools built around it.
Ghidra appears to have better support for very large (1GB+) firmware images with decent performance. It also doesn't have problems with analysing firmware images that declare large memory regions. IDA historicallly has had problems with this and it can be quite frustrating.
Anecdotally, Ghidra's support for disassembling Windows OS binaries (e.g. kernelbase.dll) is currently broken due to some bugs with the x86 instruction decoder. There are issues on GitHub talking about this.

These points are true at time of writing (March 2019) but may change over time.


How can a customer authenticate EPOS device and make sure it's not fake? In the scenario where customers use magnetic stripe payment cards and are paying via EPOS, a merchant can put a fake EPOS on the table that looks identical to real ones, the customer uses his card on this device and enters his pin.

This device records card information and the pin entered and says that it failed to connect to the bank or the payment gateway.

Then the merchant tells the client to use another EPOS which is genuine and the payment succeeds. It's like phishing but in real world with physical devices.

In this scenario there's no way for the customer to authenticate this EPOS device and make sure that it's the real device and connected to bank network.

Are there any methods currently being used to mitigate this risk? What are some countermeasures to put in place, not to fall for this attack?

(reminder) these devices are tamper resistant meaning you can't open them up and manipulate the circuitry but the scenario above, uses a totally fake device that just looks like real EPOS devices.

Switch from magstripe to chip cards

The only way for preventing a fraudulent merchant or POS from impersonating a customer/card is by ensuring that the card data cannot be copied and cloned by the merchant simply by having the card available during a normal payment process. The switch to EMV chip cards was intended as a solution for this and other problems.

The scenario that you describe is very similar to other popular attacks like a third party attaching a skimming device (e.g. on ATMs) or a dishonest waiter swiping a card in a real terminal and also another card reader. The customer can spot such risks in some cases, but in general they cannot eliminate the risks, cannot do a full validation and will have to trust the merchant and accept some risk or not use magstripe payment cards.

The main practical way for fighting this type of fraud is by identifying common point of purchase after fraud has happened, and verifying identities of potential merchants - so that it becomes impractical to do this because you're very likely to get caught soon, and it's not that easy for such criminals to recreate new legit merchant connections many times.


Should the email address in the SOA be used to validate domain control? I'd like to validate the ability to own a DNS domain and am already considering validation that is currently in use by others such as

Email validation of Whois contacts
Access to the "postmaster@domain.com" or "admin@domain.com" email addresses
A special CNAME entry that is set to an arbitrary value

Question

Since control of DNS is what I'm targeting, is email validation of the SOA record in a given DNS zone sufficient validation for a domain?
How much confidence should I give to someone who validated their email address from the responsible mail addr in a given DNS SOA record?

If you send an email to an address that you find in the SOA, you are not, technically, validating control of the domain; you are validating control of that specific email address. Which is not the same thing.

To really validate control of the domain, send a challenge to the purported domain owner: make him create a new entry in the DNS, e.g. a TXT field, or a custom CNAME. If the requested entry appears, then yes, your interlocutor appears to be in control of the domain. As for any challenge/response protocol, the challenge ought to be unpredictable (i.e. the custom CNAME should include a big random name element).

Email addresses in the SOA are not necessarily up-to-date. Most SOA have this address because it is part of the format, but it is rarely verified so I guess that many domain have an incorrect address there, or an address ending in a mailbox which nobody looks at. In any case, I don't think that many people consider that putting this address in the SOA constitutes a delegation of power over the domain to the individual who would happen to be able to read emails sent to that address (especially since emails are not exactly the most protected communication system ever).


Can a JTAG device be attached to a running system? JTAG, or Joint Test Action Group, is a standard for debugging. Many modern motherboards, both on mobile devices and on desktops and workstations have JTAG ports. They allow a CPU to be controlled like a puppet, primarily for debugging. I have heard conflicting information about the use of JTAG. On the one hand, I've heard that the JTAG ports have to be inserted, then the CPU reset for it to work. Is this true, or can JTAG be used while the system is powered on and running? If it can be used while the system is running, what mitigations are there to prevent it from being used as an attack vector to hijack a running system? I am specifically curious about the use of JTAG on modern server motherboards sporting Intel CPUs, not so much on mobile phones. I do know that you have to sign an NDA to access to tools required to use their JTAG port, but hopefully this question is not covered by such restrictions.

In other words, does JTAG support hotplugging to control a CPU like PCIe, or is it more like PCI where you have to plug it in and reboot the system with it inserted for debugging (and attacks) to work?

Actually, on modern processors JTAG access and the level of service that can be reached with JTAG is controlled by OTP fuses inside the SoC, or in case of Intel processors with patches to the CPU RTL.So on development systems, not fused, it is fully possible to attach to a running system with a JTAG system like T32. But in production systems I do not see a security issue.


How to determine whether site is secure from common user's point of view? What should be done (or at least declared) so end-users, visitors will start trusting your website?

Some thoughts:

secured login (via https)
privacy policy (hidden email and other private information)
strong password check
custom error page with feedback
recaptcha

https/SSL everywhere. Securing just the login is useless, as its trivial to steal session cookies from unsecured connections (see http://codebutler.github.com/firesheep/).

Never send them their password. In a proper designed system, that is impossible anyway (only storing hashed, salted passwords, not the actual password). Yet way too many sites still do that.


How to get a SSL Certificate for a public IP I am using Amazon's EC2 to host my RDS database. I access the database via http calls to the EC2 instance, which in turn contacts the database. I would like to use https instead to allow for a more secure connection.

I am new to the world of security. From what I have read so far, I need to get a Certificate Authority to validate my domain. I pay a fee and they will validate for a certain time frame.

1) Can I use my Public DNS address to get the SSL certificate?

2) Are there any free CA's that are known as trusted that I can use to obtain a certificate?

3)I want to use https because the EC2 instance will be handling user login. Should I go ahead and use regular http and send information that way instead of trying to set up https?

Any and all advice/input welcome. Thanks in advance.

1) Can I use my Public DNS address to get the SSL certificate?

No; to quote this Amazon tutorial,

If you plan to use your EC2 instance to host a public web site, you
need to register a domain name for your web server or transfer an
existing domain name to your Amazon EC2 host.

The "Public DNS address" from Amazon (which looks something like ec2-1-2-3-4.compute-1.amazonaws.com) won't work because you are not Amazon.  You need to get your own domain so that you're authorized to get certs for it.

  2) Are there any free CA's that are known as trusted that I can use to
  obtain a certificate?

StartSSL is the traditional answer for this, but they're under a cloud and probably don't fit what you call "trusted".

LetsEncrypt is another good answer that will probably fit your needs, especially where it's you needing access to your service (and not, say, a wide customer base of varied people and browsers).

  3)I want to use https because the EC2 instance will be handling user
  login. Should I go ahead and use regular http and send information
  that way instead of trying to set up https?

No, there's a hundred good reasons to use HTTPS, and very few good reasons not to.


Whats the point in having software's like Veracrypt, which end of the day needs password to decrypt? There are encryption softwares like Veracrypt which encrypt data and the only way to open encrypted file is via password, but a simple compressing softwares like RAR also provide password protection.

Now the problem with password is that: it can broken using brute force attack.

So my question is, what makes Veracrypt any different from RAR softwares in case of such attacks, what's point in encryption?

Encrypted archives are fine if you want to send encrypted data to somebody else, or perhaps to encrypt a backup.

Disk encryption software like TrueCrypt target different use cases:

You can encrypt your system drive. You get prompted for your password on boot. If somebody steals your computer/hard disk they can't read your data without guessing the password.
Mounting encrypted partitions and containers. Once you mount a container all the files in it are accessible to every program transparently, instead of needing a specialized tool.

Since you can use any filesystem supported by you OS on top of a TrueCrypt container (file, partition or whole disk). These filesystems support efficient random read- and write access. Compressed archives are meant to be created and unpacked as one long operation, they're not suitable for mounting.

If I remember correctly, rar uses ECB mode for encryption. This is very bad for uncompressed data, but compression should eliminate should remove most of the plaintext structure/repetition, so it's slightly less bad in the common case of compressed files in a rar archive.


Secure communication between two applications on the same system I'm writing a software which is divided into two separate stand-alone pieces. One is a service like application that handles all the logics, the other one is a GUI application that just works as a front-end and is aimed to be used by the end user. The service would listen to a port and accept requests from the client (GUI) application.

Since some sensitive information is exchanged between the service and the GUI applications, they need to be encrypted before getting transferred. One way to secure data is to use a key based encryption but keys need to be stored somewhere on the disk or even in the application's source code, but would rather avoid using keys.

How can I handle a secure connection between service and GUI application without using a key-based encryption algorithm?

These are the golden rule of computer security: "It is impossible to hide anything from a competent user with system administrator privilege" and "any competent user with physical access to the device can always elevate himself to system administrator".

You cannot hide any information from someone with physical control of the machine. If the secret you are trying to hide is really important, then you should never transfer the data to the machine and do your processing elsewhere in a place that you control.

Your program is running on a user's machine. You cannot protect your data from the user. With that in mind, does this mean we're doomed? Not necessarily. The operating system provides a wealth of mechanism for programs to communicate privately with another program that will not allow another unprivileged application to intercept it. So, while you cannot protect any data from the user themselves, you can protect your data from another unprivileged program. Providing security boundary between unprivileged programs is one of the main job of the operating systems.

The simplest of this is an anonymous pipe. A pipe allow a unidirectional stream of data to be transported between program. Anonymous pipe is available in Windows, Linux, OSX, and all Unix-like systems. Anonymous pipe most commonly recognized as a pair of pipe called stdin and stdout that allows a parent process to send and receive a stream of data to and from its children. Anonymous pipe can only be used between processes that have parent and child relationship. There is also a named pipe, but they behave differently in Windows and in Linux/Unix-like systems, we will get back to this later.

Another IPC that are commonly available is sockets. Sockets is like a bidirectional pipe. There are many different sockets but they work similarly. The most commonly known is TCP socket. TCP socket is primarily intended for networking between machines but you can also create a loopback TCP socket which can only be used within the same machine. A loopback socket provides privacy (only the program the program that connects and the program that listens can read the data passing through the socket), however it does not really provide mechanism to restrict who can be the other side of the socket.

Another type of socket available in Unix for communication between processes in the same machine is Unix Domain Socket. A Unix domain socket is exposed to programs as a "special file" in the filesystem, and unix filesystem permission is used to control access to the socket. A domain socket cannot be connected to by programs that does not have the right access permission to access the socket file. In Unix-like systems, this means that your service and GUI should run as the same user and/or group that are reserved only for your program and you set the socket file permission appropriately.

Let's get back to named pipe. In Linux/Unix-like systems, a named pipe is pretty much like stdin/stdout in that they are unidirectional. In Windows, however, a named pipe is actually bidirectional and is pretty much the equivalent of Unix domain socket in Windows. Like a lot of things in Windows, named pipe is secured with ACL.

With iOS things becomes a bit hairy. A non-jailbroken iOS only allows a very limited set of inter-process communication, and neither will give you a socket. But if we play loose with definition, in the iOS application, the service program and the GUI program is probably going to actually be the same application, and thus you can simply create a stream directly between different components of the application. This is also secure as the stream is accessible only within the application.

Android provides more options for IPC, including the ability to create domain socket. The API is different but they are conceptually similar with regular Linux. Alternatively, you may go the same approach like in iOS and package your service and GUI in the same application and just use in-process streams.


intercept TCP traffic on compromised router I have this configuration
GATEWAY1 <----> ROUTER <---> GATEWAY2

I am on the compromised router, and I want to intercept/block the packets that come from G1,edit them , and forward on Gateway 2,acting as a MiTM.
I know that I can edit packets with Scapy, but how I can stop them to reach the original destination?
Gateway 1 and 2 are on Debian "squeeze".
The Router has Kali.

Simply drop the packages you don't want to forward.
Routing is an active task, and the router has to decide what to do with each packet. Scapy itself doesn't allow dropping, because it's simply a passive sniffer. You can either use the python-iptables package to drop the packets, or use a different MitM solution altogether.


I ran a virus on a PC. What should be the next steps? I wanted to remove a probably malicious executable, but instead inadvertently double-clicked on it while using an account with administrative privileges. Nothing visible happened during a few seconds, then the executable removed itself (something a legitimate executable wouldn't probably do).

My next steps were:

Ensuring Avast definitions are up to date.
Disconnecting the machine from LAN to avoid affecting other machines.
Doing a full scan with Avast; this revealed no viruses.
Checking for suspicious entries with Sysinternals' Autoruns: I don't see anything wrong there.
Trying to run Sysinternals' RootkitRevealer, but it won't run on Windows 8.
Runing Sophos Anti-Rootkit and Kaspersky TDSSKiller. No rootkits found (Sophos Anti-Rootkit found a bunch of hidden registry keys and hidden files, but those are likely to be legitimate files).
Checking services.msc; given the number of services, it's difficult to check if all are legit.
Running sfc /scannow. Nothing wrong there: "Windows Resource Protection did not find any integrity violations."
Watching resources usage for a few minutes. Looks like there is nothing exceptional either.
Checking the list of Chrome extensions. Nothing wrong there. Internet Explorer is not installed, so nothing to check there.

It looks like the PC wasn't infected, but I'm still scared to reconnect it to company domain. I would like to avoid reinstalling Windows, since it would annoy a lot the person using the concerned machine.

What should I try next?

All the steps you have taken are valid steps for malware-removal.

I suggest, to be 100% sure, you download and use (via a USB is good enough) the program Malwarebytes (the free version is extremely powerful, the "full" version only adds "24/7" protection if booted).

An other program that is handy to have in possession, and use in this case, is our old-school Hitman Pro, a really powerful "Second Opinion" program that is included in a lot of Rescue/boot discs (think of Hiren's Boot Disc as example).

If all those lights show green, I wouldn't worry too much about it, of course, whether or not a PC is infected is always a question, there are always chances you are infected with malware that escapes software, that's the reason why you should always scan/remove with more than one program!


How can I prevent my kids from bypassing my computer restrictions? My son has a downloaded copy of Ubuntu that he uses to "break" into my computer, bypassing Vista. I have two questions:

Can this damage my computer or corrupt my files? (I have lots of pictures)
Is there a way for me to block this disc from working as there are strict rules in our house for usage time on the computer and time limits?

This issue has come up on a couple SE forums already, so most of this is going to just be echoing my existing answers.

How can I prevent someone from accessing a Windows XP system via boot disk?

How to secure my Windows 7 PC?

A couple of fairly major issues exist here, which are really working against you:

Unless there's something you haven't mentioned, your son probably has relatively unrestricted physical access (in terms of actual security) to your system.  I'll cover some mitigations you can put in place below.
It seems your son is lacking a certain respect for you and/or your rules regarding computer usage.  If you'd like assistance with this, I'd point you to the Parenting Stack Exchange.

Regarding physical access to the computer:

As security compromises of a PC go, physical access is perhaps by far the worst kind.  Once an attacker (in this case, your son) literally has their hands on your computer, most other security methods in place are easily circumvented.  That said, here's what you can do to prevent or hinder these attacks from affecting your system.

Use strong passwords.  Make them 15 characters long at minimum, and use all four character types (lowercase letters, uppercase letters, numbers, non-alphanumerics).  Avoid using any dictionary words in any part of the password.  You should also avoid using anything that would be common knowledge, like a pet or friend's name or someone's sports jersey number - this especially applies when the threat is coming from a family member, who would have intimate knowledge of such things that are dear to you.   Lastly, do not write it down!  This will help better secure any resources that are password-protected, although physical access to the system can bypass most password protections that do not use encryption.  For protection against physical access, also see item 4.
Encrypt the hard drive.  This will prevent any attacker from reading or manipulating the system files when booting into their own environment.  This is the only measure that will generally survive an attack involving physical access to the system.  Also, see item 1.  While this will help ensure your data is not read or modified, it cannot prevent use of the system via boot disc (like your son is using) or attempts to intentionally destroy the data.  See items 3 & 4 for that.
Lock down the BIOS and Boot Order.  Set the system to only boot to the system drive, and set an Administrator password on the BIOS so that this cannot be changed.  Optionally, you can also configure the BIOS to require a password at boot-time regardless of what boot media (CD, Hard Drive, Flash Drive, etc.) is going to be used.  Also, see item 1.  This will prevent your son from booting from a LiveCD, but it is reliant upon physical security to prevent bypass.  See item 4, regarding this.
Physically secure the system case.  If possible, lock the system's chassis with a padlock and/or place it in a secured cabinet.  A chassis lock will hinder efforts to clear the BIOS password by using jumpers on the motherboard, and efforts to remove the hard drive for loading into another system.  A secured cabinet will do that, and also hinder any attempts at plugging in or loading alternative boot media.  More generally, you could also just lock the room the computer is in.  For ideal security, and if you're really paranoid, do all of the above.  This really should be at the core of your solution.  Without this, your BIOS password can be easily bypassed and your son could boot from whatever disc he likes.  At that point your data, if encrypted, may still be safe from being read or modified but it could still be destroyed either intentionally or accidentally.

Also, for the first part of your question:

  Can this damage my computer or corrupt my files? (I have lots of pictures)

Using a boot disk generally does not pose any inherent risks to your system's integrity.  However, at this point your data is at the mercy of whomever is at the keyboard.  If the system can be booted from removable media, whole-disk encryption may protect the data from being read or modified but it cannot protect the hard drive from being completely wiped if the attacker intends to do so.

Your best defenses here would be to follow the steps above as far as they are practical for you, and make sure it is understood that your rules will be strictly enforced with stiff penalties.


Keystroke logging in virtual machine with soft keyboard In conjunction with this question:

Keystroke logging and virtual machines

I'd like to ask if for example, while using the VM, could the keylogger (keylogger inside host) still log if I was using a virtual (soft) keyboard?

Other info:

This screenshot was from an Android emulator with soft keyboard settings turned on.

Some keyloggers capture inputs to virtual keyboards by taking screenshots whenever the mouse clicks. This is still effective if the host has a keylogger and the guest VM is using a virtual keyboard.

The host OS receives the click from the mouse and then passes that event on to the VM. The keylogger on the host could take a screenshot at that time.

Screenshots are just one way of capturing inputs to keyloggers, but it's the example you are looking for.


Can cascaded routers protect inner network's machine from attacker from outer network? Given:

Outer Network

router A

wan ip 209.123.12.11
address 10.10.0.1

machine A

address 10.10.0.10
gateway 10.10.0.1

Inner Network

router B

wan ip 10.10.0.100
address 192.168.10.1

machine B

address 192.168.10.10
gateway 192.168.10.1

Known:

machine B can access machine A
machine A cannot access machine B (please correct me if I'm wrong)

Question:

If machine A is hacked, and the hacker places a sniffer on 10.0.0.100. Is machine B still being "protected"? e.g., if user on machine B goes to a webpage without HTTPS and make a login, can the sniffer capture the traffic?
If it's not protected, any advice on the infrastructure change can be given?

I presume that by "router", you mean each of these is a "router/NAT/firewall" combination appliance.  Most home routers include firewall capabilities, which is most likely what you're relying upon here.  (Note that NAT is a connection sharing technology, but not a defense mechanism.)

To directly answer your question, if a hacker gets inside your first router A, the answer is "yes."  He could install network monitoring software (such as wireshark) on machine A.  He would then have a couple of options to get the traffic into machine A to be monitored.

He could reconfigure router A to mirror all LAN traffic to the hardware
port where Machine A is located (a common task when installing a
network monitoring device; many routers and switches support this.)
He could reconfigure your router A to act like a hub, automatically mirroring all LAN network traffic to all ports (may be possible with some cheap consumer routers.)
He could configure machine A to act as a router.  He could install and run DHCP on machine A, assuming router B is getting its external address via DHCP it could respond that its gateway is 10.10.0.10 (machine A's address.) That way all traffic from network B would be routed through machine A, where it would be subject to monitoring.

This would only give the attacker the capability of monitoring unencrypted traffic; but it still would not permit him to decrypt the contents of https/TLS/SSL encrypted streams.  It would also not permit him to see LAN traffic inside router B, so if you were printing from machine B to another printer on the 192.168.10. network, he would not be able to capture it.  (At least not without breaking into router B.)


Disabling/Destroying CCTV/IP Cameras with Lasers? @D3C4FF has asked a great question and I would like to follow up on that. Basically he had asked whether "[...] an attacker can identify if a CCTV camera is on/operational without direct physical access to the cable/camera[.]".

I was highly impressed by @TildalWave 's answer, and particularly about disabling cameras: "[...] all you need is a decent pocket/torch size green laser (532 nm) directed for a few seconds directly into their CCD/CMOS sensor.".

I remember some 10 years ago kids in my neighborhood had found out that you could 'DoS' the street lights using the same technique (by pointing the laser to a point near the back of the light bulb). I figured out that this was because those posts light automatically when it gets dark (meaning lack of light) and as soon as it gets bright (meaning light went inside its sensors) the light would turn off.

So I would like to ask:

1 - How does this laser attack apply to cameras?

2 - For which types of cameras does the laser pen attack work against (CCTV Vs. IP)?

3 - Is the laser pen attack the only vector against those devices (apart from obvious things like fire, TNT, acid, shooting, etc)?

4 - Why are cameras still vulnerable to it, if at all?

5 - Finally, how can I prevent those type of attacks against my cameras (they are all IP-based)?

Just a quick edit for those who (like me) was not sure whether this question was appropriate for the site, I have posted a question on Meta.

I've experimented with this attack previously.

It depends on a few variables. First, the strength in mW of the laser you are using. Second the quality of the camera you are trying to disable.

1 - How does this laser attack apply to cameras?

A laser creates a super bright and focused spot on the CCD (camera sensor). This spot can be bright enough to blind the camera, or strong enough to physically damage the CCD/CMOS sensor of the camera (melting, overloading the circuitry etc). This is the type of image you'll see when a lazer is pointed at your camera:

2 - For which types of cameras does the laser pen attack work against (CCTV Vs. IP)?

It doesn't matter. It will work on ALL visible light imaging technologies. This includes film cameras, CCD, CMOS sensors etc. I've tested this with 'prosumer' point and shoot cameras and a wide variety of CCTV cameras. Being IP/CCTV doesn't change the fact that your overloading the light sensing components of the imaging sensor.

3 - Is the laser pen attack the only vector against those devices (apart from obvious things like fire, TNT, acid, shooting, etc)?

NO! Another clever one that i've used to success is wearable Infrared LED clothes (usually on a hat). This is essentially the same as using a bright light to obscure you from view, you will show up on the screen, but if you use bright enough LED's, it'll make you un-identifiable.

4 - Why are cameras still vulnerable to it, if at all?

Because cameras sense light, if you throw enough light at them, they won't be able to process the weaker reflected ambient light.

5 - Finally, how can I prevent those type of attacks against my cameras (they are all IP-based)?

You can't really. Its part of the design of the cameras. The best thing to do would be to identify cameras that may be vulnerable and perhaps install hidden cameras in the area so that if someone disables an overt camera, they'll hopefully miss the covert one.

For more information on this type of attack, check this guy's site, there have been a few projects like this around but this is well written up and contains lots of good example shots.


What is considered the simplest (or lightest) secure development lifecycle? Microsoft has there simplified SDL:

  "The Security Development Lifecycle (SDL) is a security assurance process that is focused on software development."

  "The process outlined in this paper sets a minimum threshold for SDL compliance. That said, organizations aren’t uniform – development teams should apply the SDL in a way that is suitable to the human talent and resources available, but doesn’t compromise organizational security goals."

For shops interested in adopting a secure SDL but without one in place or frightened by what it entails, what do you consider the simplest secure SDL to try out?

Great question.
First, the "minimum" you quoted refers to Microsoft's minimum requirements policy, not necessarily the "industry best practices" minimum. Not that I'm saying its wrong, but the MS-SDL itself does go on to say that their SDL is not necesarily fitting for any organization outside of Microsoft... In fact the MS-SDL architects, such as Michael Howard is oft-quoted saying:

  Don't do what we do, do what we did.

Which is to say, its not so much the prescribed requirements as they specifically appear in the document (though they might be mostly very good), but they repeatedly performed studies, including risk-based analysis, historical metrics comparisons, trend analysis, root-cause analysis, trials in different teams to see what "takes", etc.

There is not a well-defined, simple SDL you can just download install and go be secure. That point from MS is spot-on - you really need to tailor your SDL according to your specific organization, your teams, their proficiency, the types of products they're building, the current development process, the risk profile, etc etc. And that's really the best solution to "try out"...

Moreover, SDL is not a one-time thing, or even a question of defining and implementing the correct policy. Building an SDL is itself an ongoing process, which admittedly can take several years to implement completely. Microsoft did quite a few iterations till their SDL reached something exemplary... And it took another couple years to get it really ingrained in (most of) their developers. You can't really "try out" an SDL, because the benefit will typically not show within the first month or two - it really is a long term investment.

So, for orgs just starting out, and looking to define their SDL - I would suggest taking it slow, have someone with experience guide them in the process:

Start by mapping out the current situation, process, teams, experience, flexibility, etc.
If the teams + management are not 100% convinced of the need for SDL, and security in general, consider doing an initial security review just to drive home the problems... A pentest is often most useful here, simply because it can be quite visual (NOT because its needed for the SDL itself at this point).
Ensure at this point you have buy-in - both from an executive sponsor, and from the teams themselves. Without either, the SDL is doomed to failure.
Training! Developers like to do things right, if they know how.
Slowly add minimal additional security activities, according to the benefits you will receive for them, as compared to the effort invested - and the disruption to the dev teams. Remember, the point of the exercise is to get EVERYBODY involved in security, and not turn them off right away.
Set up security expertise, either in your team (as a security champion) or in a central team that everyone can talk to - and get them talking. Better yet, is a hybrid model of both (as in the MS model).
According to your capacity for additional security investment, in each cycle add minimal additional activities, on top of the previous ones. The point is to get them so used to doing one-two small li'l things, that it becomes second nature (almost) and it no longer "takes so very long to do this security stuff". Then you'll have bandwidth for more...
Gather metrics along the way, so you can tell what is working and what is not, and also to show the benefit from the SDL investment to management.
More training!

Now, the real problem is that list above, looks like a lot.
But it really isnt, since most of those bullets are "meta-activities". Some of them should probably be done by an experienced security guy/gal/consultant, with experience in implementing SDL in a similar type of environment as yours. Admittedly, still not so simple, but when I do this I put the emphasis on minimal disruption and ongoing investment. It can be done lightweight.


How to use postMessage securely postMessage is a primitive introduced in HTML5 that web pages can use for cross-origin communication.

What do I need to do to use postMessage securely?  What are the primary security pitfalls or mistakes that I need to look out for?

The W3C security instructions for this are surprisingly accurate and complete:

  Authors should check the origin attribute to ensure that messages are
  only accepted from domains that they expect to receive messages from.
  Otherwise, bugs in the author's message handling code could be
  exploited by hostile sites.

  Furthermore, even after checking the origin attribute, authors should
  also check that the data in question is of the expected format.
  Otherwise, if the source of the event has been attacked using a
  cross-site scripting flaw, further unchecked processing of information
  sent using the postMessage() method could result in the attack being
  propagated into the receiver.

  Authors should not use the wildcard keyword (*) in the targetOrigin
  argument in messages that contain any confidential information, as
  otherwise there is no way to guarantee that the message is only
  delivered to the recipient to which it was intended.

  Authors who accept messages from any origin are encouraged to consider
  the risks of a denial-of-service attack. An attacker could send a high
  volume of messages; if the receiving page performs expensive
  computation or causes network traffic to be sent for each such
  message, the attacker's message could be multplied into a
  denial-of-service attack. Authors are encouraged to employ rate
  limiting (only accepting a certain number of messages per minute) to
  make such attacks impractical.

The most important thing is to always validate the origin - you'd be surprised how many sites fail to do so. If the message is confidential then the targetOrigin argument must be specified.

This of course assumes that the browser implementation is correct and without holes. The major browsers have been evaluated and no issues have been found.

See also this Checklist for postMessage Security Review.


Missing Powershell Logging Options in Group Policy Editor I have configured a Windows 7 domain workstation and a Windows server 2012r2 server as the domain controller. After fully updating both machines, I followed the instructions here: https://msdn.microsoft.com/en-us/powershell/wmf/5.0/requirements to configure the Powershell transcription, block, and module logging features. To be clear, I updated Windows 7 fully, installed the latest .NET framwork (4.6.1) installed WMF 4.0, then installed WMF 5.0. On Server 2012r2 I fully updated and then installed WMF 5.0. Also, on the Windows 7 box, the options for Powershell logging were present after installing WMF 4.0, but then vanished completely after installing WMF 5.0. I have reverted to prior snapshots and repeated with the same results.

Windows 7: Windows Powershell missing completely in group policy editor.

Server 2012r2: Windows Powershell present in group policy editor, however only containing 3 settings:

Turn on Module Logging
Turn on Script Execution
Set the default source path for Update-Help

The other settings that SHOULD be present, but are missing are:

Turn on PowerShell Script Block Logging
Turn on PowerShell Transcription

Any help is appreciated. Thanks.

You'll need to update your Group Policy administrative templates (the best way to maintain this is to have a centralized ADMX template store on your DCs).

Download the most up to date templates from here:
https://www.microsoft.com/en-us/download/details.aspx?id=48257

The installer will just create a file structure of the current ADMX templates for windows - have it install the files into a temp directory that you can pull files out of. Instead of wholesale replacing all of your templates, you can cherry pick the ADMX / ADML templates that you want to update - in this case the "PowershellExecutionPolicy" template.

Copy the file "PowershellExecutionPolicy.admx" from the New Templates\PolicyDefinitions directory into your Group Policy Template store for the domain. Then go into the applicable language directories for your AD environment (my Org is US only, so I just use "en-US") and copy the PowershellExecutionPolicy.adml file into the same directories in your domain GP Template store. You will probably be prompted to overwrite existing files with the new ones, this is expected (since you're updating the templates).

After replicating between your DCs, the new options should be available.

Info on creating an AD Group Policy Template store here:
https://support.microsoft.com/en-us/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administrative-templates-in-windows


Is copying passwords to iOS clipboard secure? Since apps on iOS can access the clipboard should I worry about it when copying passwords from the keychain?

I do that when AutoFill feature doesn't work so I would not have to manually retype complicated passwords.

No, but depending on your threat model, it may not be a problem.

There are a lot of ways an attacker could read the current and past contents of the clipboard, but usually this requires some kind of malware on your machine. At that point, you have arguably bigger problems, though it does expose you to greater risk.

So in short, if these are regular everyday use passwords, its not something to worry about unless you have a reason to be particularly paranoid. I wouldn't be copy-pasting nuclear launch codes for example. See also Is a password in the clipboard vulnerable to attacks?

As a side note, many popular password managers are vulnerable to memory-read attacks anyway, so even if you were careful about avoiding copy-pasting passwords, a sophisticated enough piece of malware could still steal your secrets.


Can an administrator see all of my info on shared, private WiFi? I am currently sharing a WiFi network with my neighbor. We are on the same network. I never set up as a Guest.

My questions are:

whether or not this person can see the sites I visit, the info I input on messages, business sites, and retail sites;
if this person can see my personal e-mail messages, and facebook messages.

I don't know if you have to be tech savvy to be able to do this if this person chose so too.

Someone who has administrative access to the network you are connecting to can:

View the IP address and domain names of the site you're connecting to (based on DNS query and/or SNI in TLS) and which email provider you're using, irrespective of encryption. You can prevent this by using encrypted third party DNS (e.g. DNSCurve to OpenDNS).
The location of your access point (this is of little concern for you as you're physically neighbors anyway).
View and modify the content of any unencrypted traffic, including session keys/cookies, and passwords if they're traveling over unencrypted connection. View and modify emails traveling over unencrypted POP, IMAP, SMTP, or unencrypted web mail.
Block access to any site or protocol, irrespective of encryption. This may in many cases be circumvented with a VPN/proxy. In extreme cases, the administrator may block all proxies, VPN, and Tor.
View and modify encrypted Wi-Fi packets and its content, that is not further encrypted (e.g. with TLS)

They can't:

View and/or modify content, session keys/cookies, or password traveling inside end-to-end or user-to-service encryption (e.g. PGP, TLS). Snooping into these type of encryption can only be done if your neighbor installed a malware/certificate in your computer
View or modify the content of emails or who you are sending email to when using POPS, IMAPS, SMTPS, or encrypted web mail.

Doing these kinds of interceptions do require a little tech saviness, but it's not actually that difficult if they really wanted to learn how to snoop on you.

Also note that there are a number of other non privacy risks with sharing connection with others. For example, if your neighbor accessed illegal activity, they could potentially implicate that on you and you could be dragged into these legal problems.


Securing data after laptop is lost or stolen We have laptops encrypted and password protected. The scenario we're struggling is if user lose or report stolen laptop.
Disabling workstation in AD and doing the rest standard procedures does not protecting data on laptop if malicious user get's credentials as it's cashed locally and than access to Laptop. Chance is small but user may fake that laptop was stolen and use log on credentials to access data on laptop.
What would be the solution or technology to solve this problem?

If you're using full disk encryption, and the laptop is stolen, the thief will have access to the data only as long as a) it has power and b) the screen lock does not come on.

Assuming you have a sophisticated thief that knows this, they would be the same as a bad actor in your organization.

  Chance is small but user may fake that laptop was stolen and use log on credentials to access data on laptop.

In other words, you want to verify the laptop was stolen and (possibly) remote wipe it when its security is questionable because the person who has the laptop has credentials to decrypt it.

There are several open source and for-pay projects that do this:

Pombo
Prey
LoJack for laptops


Real-time Operation systems and attacks I'm interested on kind of attacks which can be used on 'Industry Control Systems'.

I only have found that following malwares:

switching-off/disablement the systems
stole the information

What else consequences can be occurred?

I think you really need to rethink the question, however to answer what I think you are asking (what effects can an attack on SCADA systems have) then the list would have to include:

Switching off Power
Information theft
Destruction of power plants (through
overload, oscillation, over-pressure,
disabling of safety cutouts etc - see the generator destruction video IOActive showed at Defcon)
Environmental damage (opening of oil
pipelines, opening of hydroelectric
valves incorrectly etc)
Processes running inefficiently (eg
the effect Stuxnet had on centrifuges
producing essential products for the
nuclear industry)

Basically, anything that is controlled by a SCADA system is at risk - so it's kind of the same question as "what damage can an attack on an IT system do?" - it all depends on what the IT system does.

If you can clarify your question as per the FAQ, we could definitely give you more appropriate answers.

Update: Dozens of exploits released for SCADA systems. some more info for you.


How and why does not having https allow people to trace my browsing habits if at home? How can my browsing habits be traced when I am at home on my own local network?

Technically how is it done ?

HTTPS is not designed to keep people from sniffing your browsing habits, and doesn't really protect you from this. Anyone able to sniff network traffic (your ISP, for example) can see https DNS and domain requests just as easily as http-- this allows visibility into what servers/IPs you have requested.

HTTPS only protects the CONTENT of the pages viewed, as well as protecting against man-in-the-middle attacks (modifications of pages on their way to you).

Protecting outsiders from sniffing your browsing habits involves other technologies such as TOR/Onion, or encrypted tunnelling/VPN.


When a closed-source company hires somebody to audit their code, is the auditor forced to do it in the company's office? Let's say that ACME, Inc. is making closed-source software. It's closed for a reason (they don't want it leaving their building other than in compiled form). Now, they are hiring some company/person to audit the code for them. How exactly is this done?

If I were ACME, Inc., I would want the audit person (or persons) to come to my physical location, get literally locked into a room with no Internet access, carefully frisked for any USB sticks or any other electronics both when they enter and leave. With cameras recording the screen and the auditor's face/hands 100% of the time he/she spends in there, which is carefully looked at by my own employees as it happens and/or afterwards.

However, this sounds both demeaning for the person doing the audit, and also unrealistic for anything but the biggest and richest companies. (And with a security-conscious/paranoid CEO.)

I cannot imagine that they just ZIP up their source code tree and e-mail it to the auditor or something similar. Even with encryption and whatnot, this just feels horribly insecure. I would feel as if the second the source code is sent to the auditor remotely, it's "left the building" and become "potentially public".

How is this done in practice? Do companies really trust the security of the audit companies? As I type this, I realize how silly that sounds, since they are after all paying them to find flaws in their own code, but still, something about not controlling the whole process just sounds horribly insecure.

I wouldn't be surprised if you answered that most companies these days just have a "private GitHub repo" to which they grant the auditor access in some GUI. But I would never, ever do that myself...

How exactly is this done?

It entirely depends on the company and the level of security required for their IP. In some cases, an audit must be done on premises with strict oversight. In other cases, it requires nothing more than signing an NDA and obtaining the source code digitally. There is no "standard" way this is done. To put it into perspective, Microsoft uses the latter technique for the majority of their source code ("shared source").

  However, this sounds both demeaning for the person doing the audit, and also unrealistic for anything but the biggest and richest companies. (And with a security-conscious/paranoid CEO.)

It's not demeaning, and many infosec professionals are used to on premises requirements. In some cases, even accessing servers must be done on the site, and no logs can be taken out. Whether or not it's unrealistic depends on your finances and your schedule. It is true that an on premise audit will cost more money, but it's not unusual nor demeaning for that to be done. You would want to pick an auditor who is used to that, though, so that they are familiar with the policies involved.


How is a software update done securely? So a secure boot process starts with a hardware based chain of trust. The root public key is baked into the ROM which is used to verify the low level boot loader which in turn boots the kernel. With this implemented, a software update will then be signed with the same key used to verify the kernel.

Are there any advantages if the key used to sign the kernel+system is different from the one used to sign the low level boot loader?

For one, it allows the boot loader and the OS to be produced and patched independently by different vendors. For example Intel and Microsoft.

Also, having a separate signing key for each product generally makes revocation easier; if for some reason you need to revoke or re-issue the key, only one product is affected.


Include multiple pub keys in a x509v3-cert Is it possible to include multiple public keys and the issuer's public key in one x509v3-certificate?

No.
X509v3 as per RFC 5280, section 4.1 only allows a single subjectPublicKeyInfo field.
And this is the field that contains the public key. So no, you only get one.
MPK proposal didn't make it.
It seems that there was a proposal to introduce a Multiple-Public-Key (MPK) Certificate Format in 2001, but it never led anywhere.


What does the http_uri content modifier do is SNORT I am very confused about exactly what http_uri does. Can someone explain this to me w.r.t NORMALIZED and UNNORMALIZED uri fields?

The normalized and non-normalized uri keywords works differently in snort. Normalization means parsing of the http_uri and then store into the buffer for matching. However in non-normalized uri will directly saved into the buffer without parsing.
For example, suppose the http request came like,
/somefile.php?username=%27;echo%20
Then for normalized uri every hex characters will represented in their corresponding ASCII value, so after normalization the request will look like
/somefile.php?username=';echo
then this string will get stored in the buffer for further matching. In case of non-normalized uri the request will stored in the buffer as it is for further matching.


How can an attacker identify the encryption method with only ciphertext? Assume that attacker only could obtain ciphertext, but knows that method is symmetric. Is there a way to find which algorithm was used for the encrytion?

And in general, if attacker knows the encryption method, is it helpful for the process of breaking or decryption?
What types of breaking process is there in this situation?

What you describe (figuring out which cipher was used, given only the ciphertext) is a type of distinguishing attack.  Modern ciphers are generally highly resistant to such attacks: the ideal cipher produces output that is indistinguishable from random noise.


Is my online account at a financial firm safe? I have recently opened an account at a brokerage firm, based in India, which unfortunately it seems to me is not following good measure to ensure security. But I maybe wrong since I am not an expert in this field. Hence I am asking for help.

The firm on their webpage login, restricts the password length to max 12 characters and asks me to answer 5 stupid questions such as "What is your mother's maiden name?" as a 2FA measure. For some reason in one of their FAQ webpage they also suggest that the user can answer the 5 questions with "a" since that will be easier to remember. As a added measure of security if I enter wrong password more than 3 times, my account will be locked and I'll have to reset my account using the 5 security questions. In their privacy policy they mention only one fact about account security, that they use SSL encryption. They never mention if they have had any security audit done by Verisign, Norton, or other third party.

Are they being lax in their online security? If so how much and what are the minimum measures an institution like them should take to ensure online safety of their customers account?

A 12-characters password is long enough not to be easily crackable.

Are you sure those questions are for 2FA? It doesn't make sense. Those questions are likely for helping in the recovering process, but definitively not a 2FA. That recommendation in their FAQ is pretty WTF??, guess lot of people is using that answer to their questions xD

The three attempts or lock is very strict IMO, but well, there you have added security.

In summary, if it's a legal financial firm it should have passed the PCI-DSS, so you can be sure that it has a good security standard.


Requirements for a secure session id? I'm writing a web service which stores data which will be shared between two
separate systems.

/session/requestNewSession?args=<data> => returns session id

/session/requestArgs?session=<session id> => returns <data> stored with key <session id>

The code is implemented in python in the twisted matrix library, and I've written my own session id generator:

private_secret = os.urandom(64)
def generateRandomSessionKey():
 rawdata = private_secret + str(time.time()) + string.join(map(chr, [random.randint(0,255) for x in range(100)]),"")
 session_key = hashlib.sha256(rawdata).hexdigest()
 del(rawdata)
 return session_key

Is this a proper way of generating a secure session id (unguessable)? If not, any ideas on what I should do differently?

Answer. Yes.  This is a fine way to generate a session ID.

Rationale. The private_secret will be unguessable and cryptographically strong (that is guaranteed by urandom()).  So, all you need is that the combination of time.time() and your random.randint() numbers are unique: that combination should never repeat.  That should be pretty much guaranteed.  The Python random number generator shouldn't repeat for a long time, so you should be fine.

For more, see Is a rand from /dev/urandom secure for a login key? for a related question.

Caveat.  The only risk factor I can see would be: if you run the server process in a VM, starting from the same checkpoint every time.  (In other words, before deployment you boot up the guest OS in the VM once and checkpoint it at that point; then every time you start up your web service, you start it up from that checkpoint.)  In that situation, os.urandom(), time.time(), and random.randint() could all repeat, causing you to allocate the same session ID to two different clients.  But as long as you don't use a VM in that way, you should be fine.

An alternative. A simpler way and just-as-secure implementation would be to use the following:

def generateRandomSessionKey():
    return hexify(os.urandom(16))


How to modify UDP packets in checksum field? Stephen Northcutt, SANS Director, make a pcap contest (see here) where the .pcap file had a hidden information in checksum field. I solved it using wireshark and it was an interesting activity.
So, I would like to do some challenge based in the Stephen's contest. How can I modify a set of packets to do some contest like these?

In advance, I apologize if I'm using the wrong community to ask this question. I didn't found another more appropriate.

There are different options. The easiest would be using a tool like scapy.

  Scapy is a powerful interactive packet manipulation program. It is
  able to forge or decode packets of a wide number of protocols, send
  them on the wire, capture them, match requests and replies, and much
  more. It can easily handle most classical tasks like scanning,
  tracerouting, probing, unit tests, attacks or network discovery (it
  can replace hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump,
  tethereal, p0f, etc.). It also performs very well at a lot of other
  specific tasks that most other tools can't handle, like sending
  invalid frames, injecting your own 802.11 frames, combining technics
  (VLAN hopping+ARP cache poisoning, VOIP decoding on WEP encrypted
  channel, ...), etc.


SQL Security Questions The CISO of my company is currently away and as IT manager I have been asked to send some security questions to a company hoping to implement an SQL database to manage salaries, orders etc.
I have very little experience regarding SQL, I have included my list of 9 questions below, have I missed any obvious questions?

How does your solution protect against SQL Injection attacks? Your application has an wide amount of functionality, do you utilize Prepared Statements, Input Validation etc?

How does your product protect the usernames and passwords for accessing the database? Are the passwords hashed and salted, if so which hashing functions and salting mechanisms do you use? Additionally, if salts are being used are different salt values used for each individual password?

Is your solution regularly tested with penetration tests? If so how often and please would you provide the name of the company that carried out the testing? Also if we have an independent penetration test will this break any Terms of Use, ie are we still covered to receive full support and services from you?

Regarding backups, you mentioned that these can be implemented for automatic backups, can encryption of the backups be done automatically through your product also or is this done manually?

I noticed that you are using SQL Server Version 2014, is it possible for this to be migrated to a newer version?

You mentioned about costs changing for each database if the workflow is different, regarding this if we wanted to start using your solution only in a LAN environment (no remote access) and wanted to include remote access at a later date would this cost us more? I imagine this is simply a case of opening a port on the server.

You mentioned that you are able to implement VPN access to the SQL server, which VPN protocols does your application support? L2TP, IPsec etc?

Are there any logging capabilities included? Can the admin see which user logged on, what actions were taken and from which IP address or do you provide an Intrusion Detection System to do this?

WRT upgrading:  Don't ask if it's possible, demand to know when it will be upgraded and to see the upgrade path to future versions of SQL.

WRT logging: there must be logging.  As a customer, I want to see whether anyone has done anything with the database, including vendor admins.  Who has rights to logging?  What reporting will I receive free of charge? Who can run reports?  Who has rights to the audit logs?  (I want to be sure that, if someone goes rogue, that the rogue employee doesn't have rights to remove their actions from the audit log)

What about physical security to the data center where it will be housed?  Who has access and how is that access determined?

Are background checks performed on their employees with access to your data?

Are "least privileges" maintained with respect to your data?  How often is access reviewed?  How long does it take to remove the rights of terminated employees (whether willfully or unwilling) from your data?

Are all default passwords changed?

Those are some of the questions we often ask of outsourced providers; apologies if you already ask these questions.


Are there any reliable estimates of the password cracking abilities of nation states? For the purposes of evaluating a hashing algorithm against the threat of a nation state adversary, are there accepted estimates of the password cracking abilities of nation states - or is there an accepted benchmark to estimate the impact of such a threat?

For instance, it has been proven that FPGAs can accelerate attacks on BCrypt. Are there any known, reliable sources which estimate how much more of an advantage an entity like NSA would or could have, with access to custom hardware and scientific computing power?

A concise answer as to why this is impossible calculate / infer is acceptable if the question is not, in fact, possible to answer. I imagine, you could come up with a worst case scenario by cross referencing published budgets against known scientific computing power in less secretive fields, but I don't know if that is something that has been done in the past.

It is in fact doubtful that "Nation States" are really interested in cracking bcrypt. Cracking bcrypt is what you do when you purloined a list of password hashes from a Web site, and want to obtain some of the passwords to be able to log into these accounts, on that site, or on other sites under the assumption that people tend to reuse passwords. Logging into accounts is active: it tends to leave traces. Spy agencies who deal with some "serious customers" (people who plant bombs, not people who send spam emails), usually, abhor leaving traces of their activities.

What a Nation State would really love is to be able to break password-based encryption, the usual suspects being then GnuPG (with the command-line option -c to password-protect a file) and TrueCrypt (for the people who still use it). Neither uses bcrypt as password-based key derivation function; GnuPG uses its own construction called Iterated and Salted S2K, while TrueCrypt relies on PBKDF2 with 1000 or 2000 iterations (depending on the underlying hash function). There are various estimates of how fast one can go about cracking passwords with these functions; this depends on the number of iterations, which may vary (especially with GnuPG, where this is done with a simple command-line option). See for instance this question for some discussion and pointers.

Basically, both for GnuPG and TrueCrypt, the easy, efficient, and above all discreet hardware to use is GPU, because these are off-the-shelf and benefit from very high production volumes, thus allowing for heavy cost reduction. While theoretically some dedicated ASIC would be even better (almost by definition), it would take a huge number of units (think millions) to actually make it worthwhile from the attacker's point of view. In the case of bcrypt, we often talk about FPGA because bcrypt is quite GPU-unfriendly; but this does not extend to PBKDF2 and OpenPGP's S2K, both hugely benefiting from GPU and making FPGA, comparatively, less attractive.

In my experience, governments are very good at spending money, but not necessarily at getting their money's worth. This partially comes from the fact that a government is not a business, and thus does not have much incentive in terms of cost reduction and RoI. However, let's suppose that, by extraordinary, some big Nation State actually achieved efficient usage of taxpayer money. Then we can make estimates.

For really serious attackers who think in the long term, the dominant cost is electrical power; that cost exceeds the cost of buying and replacing the hardware. For computing centres, the relevant notion is that of Power Usage Effectiveness, which qualifies how much extra energy is needed when feeding your hardware (for cooling, lighting and so on); a PUE of about 1.2 would be already quite good (that's about what Amazon, Microsoft and Google say they achieve). For some discussion on PUE, see this report, especially section 4.

Let's throw some figures at it. An AMD R9 290X can compute about 4 billions of SHA-1 per second (see this site); a 2000-round PBKDF2 with SHA-1 involves 4000 SHA-1 invocations (2000 HMAC/SHA-1 calls), so that's 1 million per second on that GPU. That beast is rated at 250W of Thermal Design Power, a figure that we will use for our estimates (in fact, GPU involved in such compute-intensive tasks tend to consume more than their advertised TDP). Thus, in one hour, the system will hash 3.6 billions of passwords, and consume 300 W·h (250 W·h for the GPU, but this becomes 300 with a PUE of 1.2). Average electricity cost in the USA is about 0.10$ per kW·h, so this put the cost at 0.03$ for hashing 3.6 billions of password. Said otherwise, for 1$, you get to hash 120 billions of password. This is close to 237 so let's keep that figure.

Now, the NSA has an annual budget estimated to a bit more than 10 billions of US dollars (the real budget is classified, but the money comes from taxes so it can still be estimated quite accurately). Assuming that they spend all of it on cracking TrueCrypt passwords, and do so very efficiently (both notions being quite preposterous), then this would allow them to crack up to 10 billions of passwords with an average entropy of 38 bits, per year (38 and not 37, because on average brute force explores half of the space before succeeding). I find it utterly improbable that they could really achieve even 1/100th of that performance, though -- both because they have a lot more other things to do with their budget, and because I don't believe that they would achieve Google-like efficiency. That would put them at 100 millions of passwords per year, as long as the passwords have 38 bits of entropy on average.

While 100 millions if a huge figure, remember that entropy can bite them hard. If they stumble upon a password with 66 bits of entropy (e.g. a password generated with the correct horse method expanded to 6 words, thus still highly human-compatible), then it would take the NSA 2.5 years to crack that password (on average), and they would not be cracking other passwords during all that time. The password had better be valuable -- and the terrorists would also have to be courteous enough to delay the execution of their nefarious plans for a few years, so that the NSA has time to catch up.

Note that TrueCrypt is not very good, as far as password hashing is concerned. It uses PBKDF2, which can be very efficiently optimized on GPU (contrary to bcrypt). It uses only 2000 iterations, a very meagre value. And yet, a single human-compatible password can still defeat the whole of an idealized NSA that would have magically become more efficient than any other government agency in the World.

Presumably, an efficient government agency involved in cracking passwords would have made the same estimates as above, and concluded that they'd better not invest all their budget into password cracking, since it can be so easily defeated. From this I conclude that password-cracking abilities of Nation States are not as high as they are often cracked up to be.


Can a rogue app hijack an ssl session of another app on the same phone? We've been discussing a possible attack vector where a rogue app with root rights could hijack the legit ssl session of anther local app and transmit its own data over it without the server being able to detect it (Edit: our app uses ssl cert pinning).

What would the rogue app need to do to achieve that?
Are there any documented cases (especially for Android)?
How could we prevent this?

(I know, the rule of thumb is that there's no protection if the attacker has root access, but we wonder whether this was / could be exploited in a practical way)

It would be possible. The app could act as a ssl proxy. For example if you were to browse to google.com the ssl proxy app would retrieve googles ssl cert. The ssl proxy would then supply you with it's own generated ca certificate. This would generate a ssl warning in your browser. However if the app installed that it's own generated ca certificate to trusted root certificates it would display no ssl error. Therefore you would not detect your connection being hijacked. As for documented cases I haven't seen anything like this. I don't know enough about the android OS to prevent this but I'm sure there would be ways.


Is it safe to use an executable if only unknown antiviruses detected something? Recently I downloaded Open Shell application and checked it via VirusTotal.
Most famous antiviruses like Bitdefender, Nrothon, Kaspersky found nothing.
But some of antiviruses thing there are some bad stuff in it.

A lot of security and administration tools get picked up as something like "Potentially unwanted program"  it may be that Open Shell has been detected as being used in conjunction with attacks (which is perfectly plausible)
The 'W32.AIDetectVM.malware2' flag could plausibly mean 'Virtual Machine' i.e. 'we have detected that this application allows for arbitrary code to be executed, which could be used to circumvent malware protection' and flagged as something you need to pay attention to.  If you hadn't installed it intentionally finding a shell on your system you didn't put there is not a good sign!
Whilst it may be a false positive, it is possible that you may have a version which has been back-doored and it genuinely is dangerous in a way that only these vendors have detected; whether you trust them is a matter of risk assessment.


Cache Bank conflicts and CacheBleed: What is there to worry about? It seems that researchers have announced yet another vulnerability regarding OpenSSL, separate from the DROWN issue, called CacheBleed. You can view the research paper here.

How does it work, and what exactly should people worry about here?

Side-channel attacks are currently all the rage. The conceptual core idea is that while a cryptographic algorithm is a mathematical object whose inputs and outputs can be expressed in an abstract way, it will also run on some physical hardware somewhere, and that execution may leave traces in various ways, that might reveal bits of information about the data which is processed, in particular any private key.

It all began with the publication of timing attacks against RSA by Paul Kocher, back in 1996. In that case, the RSA private key could be rebuilt by making some precise measurements of the execution time of the RSA private operation (decryption) and correlating it with the input data.

There can be many ways by which hardware leaks information. Embedded systems, and in particular smart cards, are especially vulnerable because they get their power or even possibly their clock signals from the outside; and, more generally, they have to keep their secrets secret even when they are, as it were, between the hands of the attacker. Software platforms, e.g. Web servers, have it much easier, comparatively speaking.

There have been a lot of demonstrations in lab conditions of how timing attacks could be applied to algorithms and implementations on software platforms. There are two levels at play here:

The algorithm can have a data-dependent execution path leading to varying execution time even in the abstract model of the algorithm execution. This is what happens with usual square-and-multiply algorithms for modular exponentiation. Kocher's attack is about such an algorithm.
The algorithm may be all "constant-time" within the abstract model, but still exhibit data-dependent execution time variation, directly or indirectly, because of the way it is implemented. For instance, a window-based optimization on the square-and-multiply may still leak information because the elements accessed in memory won't be the same depending on private key bits, and this implies varying behaviour with regards to caches.

CPU cache is a pervasive optimization in all modern hardware platforms except the most reduced (smart cards do not usually have cache, but that's about it). Caches work by keeping a copy of some recently accessed data elements in a special piece of RAM that the CPU can read much more efficiently than common RAM. Details depend a lot on the cache technology (cache line size, alignment, cache-back or write-through, associativity...). Cache-based attacks are attacks that try to leverage cache behaviour. Basically, the algorithm, throughout its execution, will access some data elements, evicting from the cache some other data, so that the next read access to the evicted data will trigger a roundtrip to main RAM, which will be detectably slow (in modern systems, a RAM access that goes to main RAM may take hundreds of clock cycles).

The attacker needs some rather accurate access to the hardware to make cache-based measures. In most demonstration, the attacker can run his own code on the same hardware. This could be another process (in the mainframe model), but it also works if the attacker runs another virtual machine that happens to have been scheduled on the same CPU as the target system. Since modern CPU are multi-core, this is a normal occurrence even in the clouds with the best repute. In some rare cases, lab-level demonstrations of a network-based cache timing attack have been run, by making a call to another service on the same machine that would happen to exercise the relevant cache lines. In the network case, it still requires some precise timing (we are talking about microseconds here) so it is generally assumed to be very hard to pull off from any place other than the local LAN.

Defence against side-channel attacks entails using constant-time code. Basically, the memory access pattern shall be fixed for all possible secret values. This applies to both data accesses, and code (since code itself is also accessed from RAM). Therefore, no data-dependant conditional branches.

Writing constant-time crypto code can be tough to do. However, there are known efficient implementations, e.g. for AES. It is possible to make a good, fast and yet constant-time RSA implementation.

OpenSSL developers, however, did not go that far. They made an effort, but they tried to cut corners, and it backfired. This is what CacheBleed is about. The RSA implementation in OpenSSL is not constant-time in the sense explained above; it merely makes a spirited effort at keeping a fixed access patterns to cache lines, as opposed to actual memory slots. Thus, they were constant-time only on some very specific hardware, not on all of them, and cache-based timing attacks were still possible. CacheBleed uses the "attacker's code on same hardware" model, whose main practical incarnation nowadays would be two VM running in the same cloud.

Do not panic, though, because it is unclear whether cache-based timing attacks are really practical. We have lots of lab demonstration, but no actual usage in the wild has ever been spotted.

One important point to consider is that cache-based attacks are not restricted to cryptographic algorithms. Anything that processes secret data is conceptually vulnerable. And if a machine is dealing with encryption, then it certainly manipulates confidential data. Cryptographers tend to focus on cryptographic keys because keys concentrate confidentiality and are high-value targets; and also, that's their job. However, the scope of cache timing attacks is larger. In other words, if cache timing attacks apply at all on your system, then you have a big problem and the cryptographic layer is only a small part of it.

What should you do ? The same thing as always: install the security patches. It should go without saying. That it still needs to be said is embarrassing. For you, I mean.

And, on a more general basis, if you intend to "go cloud" and share the same hardware with complete strangers, well, think twice. A really good cloud provider will enforce hardware separation for their big customers, i.e. ensure (contractually and technically) that any given machine will never run concurrently two VM from distinct customers. Alternatively, there is a lot of good to be said about private clouds.


When updating a subkey's expiration date, do old backups of my private master key become invalid? In GnuPG I have a master key that doesn't expire, with separate subkeys with one year expiration time for encryption, authentication, and signing. If I update the expiration dates of my subkeys, will I need to make new backup copies of my private master key?

The expiration date of subkeys is stored in a special kind of signature issued by the primary master key on the subkey. With other words, if you change the expiration date, no private keys are changed at all. If you can restore the public key later (for example, fetching it from the key server network), you're fine.


In theory, can x509 certificates use Accumulator-based revocation schemes? How do these schemes work? On page 3 of this U-Prove document regarding toke revocation, the author says the benefit of Accumulator-based revocation schemes is

  A cryptographic accumulator allows the aggregation of a large set of elements into one constant-size value,
  and the ability to prove that an element has been aggregated or not in the accumulator.

... which when ported over to the x509 certificates world, means that the CRL would be of a constant size.  This is important to many people who manage revocation or OCSP

Also, in the footnote

  Many accumulator-based schemes rely on bilinear pairings, common in the cryptographic literature, but not
  yet popular in industry systems and standards.

This makes me wonder why this optimization hasn't been ported to more popular certificate formats.

Question

What would be needed in order for the x509 PKI system to use an accumulator based scheme?
How do accumulator based schemes work?  (They speak to the role of a witness and I'm not sure which entity would manage this)
How would the load be distributed?  (Load meaning CPU or bandwidth in a high traffic area)

To put things simply, one of the goals of U-Prove is to provide some kind of anonymity (in their words, "preventing unwanted user tracking"). This makes revocation harder. In an X.509 context, where there is no user anonymity (a certificate contains the owner's name in plain words), revocation is simple: the authority who decides who is revoked and who is not simply issues signed statements about the revocation status of a given certificate. This can be an OCSP response, which talks about a single certificate, or a CRL, which lists all revoked certificate (from a given issuer or set of issuers), and thus implicitly lists all non-revoked certificates as well.

If you try to do the same thing in U-Prove, then you have invented a way to track users, and that's not good. So revocation in U-Prove must use more complex protocols, e.g. a cryptographic accumulator. Mainly, this allows each token owner to compute a verifiable proof of a token not being revoked at a given time, without opening the possibility of tracking the token owner. Revocation is still asserted by a specialized authority, so there must be some regular communication from the authority to the token owners; these are the witnesses. Each token owner must obtain a fresh witness from the authority, in order to compute the verifiable proof that the specific token is not revoked at some time.

This is not an optimization over X.509 CRL/OCSP. In an X.509 world, each certificate owner can obtain a fresh OCSP response from the CA and then show that response to third parties; this mimics the system of witness propagation but with shorter elements and less CPU cost. Moreover, in X.509, it is not necessary that the certificate owner be involved at all; each entity who wants to validate a certificate can obtain the CRL or OCSP response directly from the CA.

In other words, cryptographic accumulators don't make classic revocation more efficient. In fact, they make it less efficient. But they add a new feature, which is the possibility to maintain revocation while still pursuing a non-tracking anonymity goal. This goal makes no sense in X.509. Therefore, no cryptographic accumulators in X.509. You could try to design and implement a revocation system for X.509 which uses cryptographic accumulator, but it would provide no extra feature, and would just make the system more complex, expensive, and restricted.

(In shorter words, there is no revocation scheme for X.509 which uses cryptographic accumulators because it would be a stupid thing to do. It would be like adding an extra gasoline tank to power a horse-drawn cart: it would not help the horses go farther, even though it would have helped if the horses had not been horses, but a combustion engine.)


ShadowHammer: Limited to Windows? I've been reading about ShadowHammer over the last couple of days:

  Kaspersky researchers estimated half a million Windows machines received the malicious backdoor via ASUS' update server. But the attack appeared intended for approximately 600 of the affected PCs.

Is it known whether there any exposure to this on, say, Ubuntu?  If not, I'm trying to understand if there's a particular reason why not other than it wasn't attempted.

The software (Asus Live Update) which downloaded and installed the malicious code was written by ASUS to run on their Windows products. The goal was to automatically look for new versions of programs released on the ASUS website and update the BIOS, drivers, and applications. The update server was compromised, and malicious code was distributed signed with ASUS certificates.

ASUS Live Update was installed by the OEM as part of the Windows OS. ASUS doesn't sell computers with Ubuntu installed from the factory, so anyone running Ubuntu wouldn't have the effected software.

That limits exposure to drivers and BIOS firmwares provided by ASUS. It doesn't appear that ASUS offers Linux specific drivers for their laptops/desktops. A BIOS update though could still be effected if the malicious firmwares made their way into the APT sources.

EDIT: I looked into this a but more and it was the update software itself that was backdoored. The malicious software was hosted on liveupdate01s.asus[.]com and liveupdate01.asus[.]com ASUS update servers.  This implies those servers were intended only for the Windows application.
https://securelist.com/operation-shadowhammer/89992/


Wasn't WhatsApp messages already encrypted? According to this article, which was written in 2014, WhatsApp had partnered with Open Whisper System to make its (text based) messages encrypted. So what's the big change now that Whatsapp's announcement that it now uses encryption keys?

In what ways, if any, is using Signal Private Messenger more secure than using WhatsApp?

E2E encryption was supported by the Android client but not the iOS client until now. For this reason there was an feature to disable the encryption by the server side. This rendered the E2E encryption useless. Now the protocol is fully implemented for all clients so that tampering of the encryption by the server side should not work anymore. However, WhatsApp could change the client code at any time to implement a backdoor or something.

  In what ways, if any, is using Signal Private Messenger more secure than using WhatsApp?

Beside that WhatsApp could change any code at any time for any reason and nobody would notice it immediately there's still the problem with meta data. The E2E encryption is only applied to the content of the conversation. Everything else is just protected by transport security. WhatsApp also has access to the contact list of all users by default. The biggest problem is that WhatsApp belongs to Facebook and the business model of Facebook is analyzing user data so you can not assume that your privacy really matters to them. However I must admit that the business model of Open Whisper Systems isn't very obvious either.

Summary

Things WhatsApp can access at the moment:

When (How often) a communication happened and a user was online
Who was involved (telephone number, IP address)
How big the messages where
Contact list of all users
Google mail address of all users

Things which are protected:

Content of a message

Some people say that the introduction of the axolotl protocol was just to get users back from Signal, Threema, Telegram and similar services.


Vaudenay attack on CBC-encrypted file on disk Assume an attacker has your CBC-encrypted file and the code that was used to generate it. Also that the file has a MAC at the end.
Will the following attack work?

Strip off the MAC from the end of the file. You know how many bytes it was.
The last byte or bytes (you know how many, see above) is now the padding.
Do a Vaudenay attack on that. You know the padding scheme.
Recover the bulk of the message without knowing the key.

If this works, doesn't this mean that CBC with padding is dead?
What have I missed?

A Vaudenay Attack, also called a padding oracle attack, is not an attack on static data or the encryption algorithm. Rather it is a protocol attack that involves repeatedly passing modified messages to the server and examining the return codes to decipher the data. The underlying problem is that the padding is validated before the HMAC is validated. As the HMAC cannot be forged without knowing the shared secret, modified messages in the attack have incorrect HMACs.

In short, the attack scenario that you presented is an incorrect application of a Vaudenay attack and cannot be executed on static data.


What is the name of a vulnerability that leads to automatically opening received URLs? I've found a bug in some program that led to automatically opening URLs that were received from other users of the program.

However, while writing up a report on it, I realized that I didn't know the name of the vulnerability.

I am no cybersecurity expert, so I tried to look it up, and some search results I've got from CWE and OWASP were close but didn't quite match this.

What could it be?

What you've described is the impact of the vulnerability - a malicious URL being opened. If you're looking for a CWE, you're thinking about it from the wrong direction. CWEs describe weaknesses, which result in vulnerabilities, which result in potential impacts. Instead you should be considering how the vulnerability arose.

At a guess I'd say you're looking at some variant of 601 - Open Redirect, but that's a blind guess based on what you've said here.


Configure Linux to allow network activity based on binary? On Windows, rules can be added to the firewall to allow/deny network traffic based on which binary is sending/receiving the data.  Can this be done on a Linux box, and if not, why not?  Is it a bad idea per se, or is it just not something that the makers of Linux thought of?

This can be done via SELinux. There are examples here.