Understanding a Whatsapp account hack (social engineering?) A friend of mine (Bob) received a suspicious Whatsapp message today, seemingly from a former colleague (Alice), who claimed to have "forwarded [to Bob] an SMS with a code in it by mistake", and who was asking to send it back.

Bob unfortunately sent the (6 digit) code (received over SMS, in a message written in Spanish, although Bob's account uses a UK number, and his Whatsapp is normally in English) back to Alice over Whatsapp, after which Bob's Whatsapp app seemed to go through the number verification process again.

I received the usual "XXX's security code changed. Tap for more info" notification twice within a few minutes in my Whatsapp conversation with Bob. We have verified that the codes match (only after the second notification).

While it is clear that my friend should not have replied with this code, I do not understand exactly what happened here:

Did someone try to login to Bob's Whatsapp account? Is it possible to "move" a Whatsapp account to a new phone simply by inputing the target phone number at the verification stage?
What phone number do Whatsapp number verification SMSes normally come from?
What is the possible damage resulting from this? Would the attacker (Alice) be able to send messages "from Bob's account"?
What cleanup measure should Bob take to limit the damage/recover his account/kick out Alice?

Did someone try to login to Bob's Whatsapp account?

Yes they tried to access his WhatsApp account and they succeed.

According to WhatsApp FAQ, the message "XXX's security code changed. Tap for more info" is displayed only when you or your contact reinstalled WhatsApp or changed phones. For more details see here.

  Is it possible to "move" a Whatsapp account to a new phone simply by
  inputing the target phone number at the verification stage?

It is possible if the two factor authentication is not enabled. If 2FA is enabled it will ask for a PIN in addition to the OTP in SMS. Learn more about it here. Based on your notification I assume that 2FA is not enabled and the attacker logged into his account successfully.

  What phone number do Whatsapp number verification SMSs normally come
  from?

It varies from country to country.

  What is the possible damage resulting from this? Would the attacker
  (Alice) be able to send messages "from Bob's account"?

Once logged in the attacker will be able to send messages from his account and read any incoming messages. However they cannot access any old messages. They also cannot restore old messages from backup as it would require access to Google account.

  What cleanup measure should Bob take to limit the damage/recover his
  account/kick out Alice?

As soon you login into a new device, WhatsApp will logout of the old device. So as soon as Bob re-login into his device his account will be automatically logged out on the attackers device.

Also as pointed out in the comments log out of any WhatsApp web logins.


Physical Access Control Logging on a SIEM - Is it worthwhile? The company I work for (Manufacturing) are upgrading their Physical Access Control (PAC) System, and it will come with logging that can be fed into the our SIEM tool(LogRhythm).

Does anyone have any anecdotal evidence or Use Cases that this additional logging data has proven useful/valuable to them?

I can envisage using it to check against rules such as; if a user logs on a terminal at HO, they will have swiped in too. I'm just not convinced that this is fool proof, as people might remote onto machines.

Points to note: We're a global company collecting logs from across the world. The PAC system is only at one site. On a tight budget, and I want to make sure that I'm not wasting time.

Thanks

This data comes in handy when (if) you'd have to perform incident response. Consider the following scenario: "Employee John Doe has logged into a system at HO and immediately after data is erased." Your SIEM should be able to detail what occurred:

date: 06/30/16 11:45EST
username jdoe
MAC ADDR 00:00:00:00:00:0a
HOST IP 192.168.1.100
ACCESSED -> This machine, that machine

This data gets correlated and you should be able to determine the who, what, when, where and the how. This is SIEM. Now imagine the same scenario where username jdoe creates chaos, without being in the building. What happened, did someone else use his credentials, was his account compromised. With PAC being sent to SIEM, your SIEM appliance should be able to correlate all the events:

date 06/30/2016 11:45EST
Employee John Doe
Door Front Door East Wing
date: 06/30/16 11:45EST
username jdoe
MAC ADDR 00:00:00:00:00:0a
HOST IP 192.168.1.100
ACCESSED -> This machine, that machine

From an incident response/forensics (DFIR) perspective, you are guaranteed (legally in some instances), that you have the necessary information to act on the information. "John Doe should be arrested/fired/etc as we see he used his card to enter the building and erase data" (Smart data gathered quickly) Versus: "John Doe should be arrested/fired/etc since he erased data. We see this via his username logins." You could open yourself up to potential legalities. If you have it, log it.


Security announcement mailing list for Java I didn't find a security announcement mailing list for Java (from Oracle). How to get notified about new Java patches? I am not interested in other Oracle products.

For example Apple provides such a list with signed mails: https://lists.apple.com/mailman/listinfo/security-announce (Security-announce -- Product security notifications and announcements from Apple)

You can subscribe to Oracle's security advisory mailing list by following the instructions at http://www.oracle.com/technetwork/topics/security/securityemail-090378.html.

You should also read http://www.oracle.com/technetwork/topics/security/alerts-086861.html for more information. In particular, the section relating to third party bulletins.


Secure PXE network OS installation How can one make sure that when PXE is being used to boot a remote operating system, that the data being sent is encrypted (or at the very least that integrity is maintained)?

Would it be possible to fetch the iso with ssh?

I don't think the first part of the PXE boot can be secured. A rogue DHCP server could hijack your install. And TFTP offers exactly zero security.

But assuming you get a response from the right DHCP server and you pull the boot file from the right TFTP server, the configuration could direct the client to load via HTTPS, which would provide both encryption and authentication.

See, for example, this HOWTO on setting up a PXE installer. Substitute an HTTPS server in the config file given at the bottom.


Is the hosting OS safe to sql injection hackers by hiding admin ID? We are 1-3 guys maintaining a fairly large but clumsy developed-in-house website. With around 900+ mysql tables, and a lot of data access code in PHP. Let's say it is huge amount of code for just 1 or 2 guys to patch them all. So we decided to fix as many vulnerabilities as possible (prepared statement) but at the same time accept the fact that it is impossible to reach 100% sql-injection proof.

We have list many things we could "easily" do to reduce the risk/damage from SQLi hackers. One of them is split admin module to and internal server which is not open to the internet, this did help a lot when the hacker(s) managed to crack admin password but could not do much harm to the system.

Now we want even more: Hiding admin id from the database, admin along with moderators id are currently stored in some "Moderators" table. So we think it is easier to us to move admin ID to some (config) file , because we rarely add/remove admin. Moderators id is still store in that table though. Now hackers need to guess which user among half a million record of "user" table.

My question : with admin module not available to the internet, is the hosting server ( Ubuntu ) safe from being taken over by hackers? In the mean time, we tolerate the attacks to normal/moderator user and the intrusion to the DB.

P/S :

The website owner is gathering more $$ for ultimate SQLi fix.
It seems even prepared statement are not 100% safe:  Are prepared statements 100% safe against SQL injection?
Even a baby know hard-coding is a big "no no" but that the best we can think of ....

There's a general maxim that trying to hide information within your code base (or table structure in this case) isn't actually helping to secure your software. It's referred to as security through obscurity and is not considered good practice.

I have sympathy for your situation because I have certainly wandered into some code spaghetti in my time, but really your best bet here is to continue to refactor the code and reduce attack vectors.

When you say "crack the admin password" do you mean that someone has already gotten in and stolen the password hashes? If this is a major concern of yours, you should absolutely salt your passwords if not already doing so -- this will help make it much more difficult for attackers to steal passwords.

In terms of developing a triage and working on your refactor, I would highly recommend The 2018 Guide To Building Secure PHP Software.


PCI DSS - network design - users connect to internet via proxy; should we place it at the last hop or before firewall? We need to be PCI compliant. PCI user VLAN is connecting to Internet via proxy, but I need confirmation about the location of the proxy.

PCI user traffic flow:

PC ==> ASA FW ==> IPS (integrated firewall) ==> proxy ==> Internet.

Is this correct? Can the traffic flow from directly proxy to Internet, or do we need to have that like below?

PC ==> ASA FW ==> IPS ==> proxy ==> firewall ==> Internet

The perimeter protection for your environment will likely be your firewall so that'll be the first line of defence against the outside untrusted world. Your user network will likely be in a separate VLAN to the proxy server. This VLAN separation will likely be performed by a switch or a firewall. You proxy server may be a server or an appliance.

I'd see the set up as follows:

PC => proxy => firewall => internet


Verifying customer check in I have created a customer loyalty and reward app that works in a very simple manner. We supply cafes etc. with a printed QR code which the customers scan on each visit, using the app. Upon completing X visits, the customer is entitled a reward, e.g. a free coffee. In order to prevent illegitimate check ins, such as taking a photo of the printed QR code and scanning it at home, we supply an iBeacon along with the label. Therefore, whenever a user scans with the app the QR code, the app attempts to communicate via BLE with the relevant iBeacon. If it's found, the check in is considered legitimate.

This however has proven to have many shortcomings, the most important of which are:

The iBeacon batteries run out quite often (after a few months) and
despite the fact that the owners receive SMS to replace the
batteries, they mostly don't bother.
The iBeacon itself is relatively expensive (about $15 each) given that we offer this service for free.

Given that the incentive to "hack" this app ain't that big (you are not going to win a car or a house by the beach), one would suggest to rely only on the user's location for example to validate that the customer is indeed at the store. However, we want this to also work on delivered goods. Currently we also supply "mobile" labels that a delivery boy has with him and the customer may scan at home or work.

I am trying to think of a simpler or more cost efficient way to validate customer check ins but haven't managed to do so.

Can anyone suggest an alternative "good enough for most cases" way to do this?

EDIT

My main problem is that someone can take a picture of a QR code and scan it at home. Therefore, I was wondering how hard would it be to check the image my app "sees" during scanning at the server side. So if I uploaded an image taken by the camera, every time someone scans a label and have some "automagic" way to determine if it's a legit scan or e.g. the screen of another phone or a printed copy of my label?

Here's what a label looks like

Could I print something on the paper or the plastic label that I can identify during scanning that would be hard to imitate? E.g. making the label look green when viewed on a specific angle?

Edit
Here is a more formal answer:

Designing a security system often mostly always finding the right balance between cost, usability and security.

In the far end of the spectrum, you have your initial solution: printed QRcode that needs to be scanned. It has the lowest cost (1 piece of paper per deployment location), highest usability (a simple scan with an app) and lowest security (can be gamed by anyone with next to no equipment and knowledge).

You traded some cost and usability for a bit more security by adding an iBeacon. That was a good move but it turns out you can't seem to be able to afford neither the additional cost (the beacon) nor the lost usability (the necessity to change the battery).

So, what you should be looking for is for a solution that will be less expensive and more usable without compromizing security too much.

So, I would suggest something that is:

Still mostly paper-based (at least as far as the deployment points are concerned)
Allow you to adjust your cost/usability/security based one the specific situation.

So, my idea is to extend your QR code to include two additional elements:

A type of "rule selector" that lets you define what security profile is requred to use that code
A signature to prevent forgery.

I would then create several different rules:

The most basic type of rule would be to require your application to be geo-located close to the deployment point before validating the visit. That should be your normal deployment option.
A time limit to the validity of the code so you can generate (and print or simply display in an app) code that can be carried around.
An IP limitation that you can tie to the deployment location (so that visitors will only be able to validate their visit from the local wifi, for instance).

Such a scheme will allow you to tailor the validation you make to the situation you face and adjust the usability/security ratio accordingly.

Of course, that's not the only possible option: you can (as suggested by @TripeHound) generate fast changing codes and display them on a local terminal (for instance on a TV screen, maybe as a superimposition over the regular program) but that's a completely different cost calculation.

Initial answer:
Obviously, your issue is cost: any solution to your problem is going to require some form of active device at the location that is hard to fake yet not too expensive to deploy.

I would suggest the following:

Change your application to use the GPS location of the device.
For delivery men, generate special codes (signed) that disable GPS checks for the given date that they can print before going out.

It's far from perfect and there are several ways to cheat (for instance, take a picture of a delivery man's code)


Attack coming from multiple IPs I have an attack coming to a specific path repeatedly - every 10 minutes or so, the same exact address gets pinged.

I know this because I keep getting an error message in my Drupal logs about an attempt to access a page that does not exist.

sites/default/files/cache.php

How do I ban attempted connections to this address? I have IPtables enabled, I have various Drupal modules set to report and ban unusual traffic (but for some reason this gets through), and the file doesn't even exist.

If you just want to block a specific IP:

iptables -A INPUT -s 1.2.3.4 -j DROP

You can't reject a TCP connection which has the later intent of visiting a particular URL, because the TCP connection has to be made before that information can be transferred.

To be honest, I wouldn't worry about it. It's probably a drive-by attack against a random plugin or CMS that you don't have. If your server is responding with a 404, there's not much you can do in response. There's no real security threat to mitigate here.

That being said, you could look into installing mod_security to provide some generic blanket security protection against drive-by attacks.


How to check if our clients were compromised by security breaches in other web applications? Every now and then a known website is hacked, such as what happened to Adobe or Cupid Media.
In such incidents user data is leaked, including usernames, encrypted (and sometimes plain text!) passwords. Users who reuse their password might have their accounts in other web applications compromised as well.

The company I work for runs a large web application. We would like to protect our clients from the collateral damage of such security breaches, by reseting the passwords of users whose accounts were compromised, such as what Facebook did in the recent Adobe breach.

How can we find the leaked user lists in such incidents?

Web security guru Troy Hunt has a site called have I been pwned? which checks an email address against those associated with a number of breaches. The passwords gleaned from the breaches are not retained there, so it's useful for determining if an account may be affected but does not disclose what the passwords or hashes were that were stolen.


Privacy of Image search with https I am connected to the internet in the office where I don't want the administrator of the network to find out the contents I check (for example images).

First I use a Firefox private browsing window to not leave a trace on the computer.

Then I supposed when I search images through SSL protocol (I mean in particular https://images.google.com), the images are only shown and are detectible on my computer and not any computer in the path so it keeps my privacy

Am I safe with the scenario above?

For all practical purposes, if you are accessing the internet from your own personal computer, then using SSL alone will prevent your network administrator from knowing the exact URL (initial DNS connection will only reveal hostname) of the images you download from https://images.google.com/.

However, if you are using your employer's computer, where the OS is installed by your system administrator, then besides turning on incognito/privacy mode to clear browsing history, there are two extra things to look out for:

The first thing is to go through the list of trusted Certificate
Authorities (CA) stored within your browser to ensure that there is
no Man-in-the-Middle proxy root certificate installed, which can be use to
decrypt HTTPS connection if your connection passes through a MITM proxy.
The second thing, which is more difficult to do, is to ensure that there
are no spyware or keylogger installed on your computer. These can log your site visits without you knowing it.

A simple way to overcome these two obstacles is to boot up from a Linux Live-CD to surf the web over SSL.


.NET application protection technique against cracking I'm trying to protect my software against cracking. Protection against cracking is crucial before listing the product on market.

Info about the software:

Built using .NET C# (Framework 4.5.2)
WinForms
32 bit

I have made a several protection layers:

Obfuscation, Renaming, anti-debugging
Encrypted communications between software and API server (RSA) public key hard-coded
The client will generate a temporary AES keys and encrypt it with server public key then sends it to server, The server will decrypt the data with his RSA Private key and respond with a new AES keys encrypted with the ones provided by the client at first request. Then any communication from client to server will be signed by server RSA pub key and encrypted by AES Keys provided by the server.
Verify libraries integrity by requesting libraries checksum from API and compare it.

And the most important part is, the application will once request "custom data" from API server and store it in memory, to be used by internal software functions. When a function in the application called it will use the "custom data" as input, so there's no way for the software to operate correctly without having the "custom data"

The API server provides the "custom data" after verifying software activation code and machine unique ID.

The question is:

With all of these layers, can the software cracked?
Can the custom data layer bypassed?
If a cracker bypassed the protection layers until the "custom data" part, it's possible to clone the software with the "custom data" meaning the software can operate without need to request the custom data from the API?

What i mean by custom data is making the software hybrid, always needs data from API to function

I am counting on the "custom data" protection layer.

Please let me hear your recommendations. thanks a lot

You're wasting your time.

  I'm trying to protect my software against cracking. Protection against cracking is crucial before listing the product on market.

Even the big names in software development can't protect their software from cracking. Despite very draconian DRM that drives legitimate users nuts, it all ends up on the pirate sites within days of release.

  Obfuscation, Renaming, anti-debugging

Everyone else does this too. All it does is slightly slow down the attackers.

  Encrypted communications between software and API server (RSA) public key hard-coded

I assume you're hardcoding the public key as a form of key pinning to protect against MITM attacks. However, this doesn't work in this case, since the client is also the attacker. They can just patch the binary and replace the key with their own MITM public key.

  Verify libraries integrity by requesting libraries checksum from API and compare it.

Doesn't work. If the check is on the client, the attacker will just patch it out. If the check is on the server, then the client needs to report the file contents to the server, and the attacker will just make the client lie.

  With all of these layers, can the software cracked?
  Can the custom data layer bypassed?
  If a cracker bypassed the protection layers until the "custom data" part, it's possible to clone the software with the "custom data" meaning the software can operate without need to request the custom data from the API?

Yes, yes, and yes.

If you want any of your data to be safe from the person whose computer is running your client, then the client needs to not have access to any of that data. It all needs to be handled exclusively on the server.


Is SSL session based only? Is there a (formal) definition of an SSL connection? In various docs on SSL there is a mention of connection.
But from the context I am not sure if this means the underlying TCP connection or the SSL connection.
I am thinking that there is no SSL connection (formally defined) in the SSL protocol and only an SSL session.
Therefore if I read for example:

  For each SSL session, multiple connections can be setup. Each connection uses the same session parameters but different key

Or

  An  SSL session can outlive the connection which produced it

The connection is the TCP connection right?
Formally speaking is there ever a SSL Connection?

When SSL is set up, it undergoes a handshake. This handshake allows the two clients to securely decide the details of the conversation and exchange key material. Once the handshake is complete, both sides can communicate securely. This entire conversation is simply an exchange of messages, so SSL is not technically limited to any transport protocol. You could run SSL over UDP if you really wanted, though standard libs probably don't support it and I wouldn't suggest trying it.

To answer your question fully - there's no such thing as a message in the SSL protocol to say "this SSL session is ending". The session is tied to whatever logic is provided by your transport layer and application layer, and it's up to the SSL implementation to deallocate resources when the conversation has "ended".

One thing your application might do is create an SSL wrapper around a TCP connection, send a few messages, send a "I'm done" message, tear down the SSL wrapper, then go back to the first step without closing the TCP connection. This way you could run multiple SSL "sessions" in serial using a single connection. I'm not sure what the use-case is, and I'd just make a new connection, but there's no technical limitation to stop you.


What does hardware full disk encryption imply? I read the wikipedia article and few others, however I still don't have some things clear. The main question would be what does hardware full disk encryption imply for the user, however I have more specific questions related:

Can I use the Samsung 840 EVO with an external 2.5" USB 3.0 case?
If so, would I be able to change it from one case to another or to the motherboard?
If yes to both of the above, what is the encryption actually doing? Stopping a hardware read/write while the disk pcb is off? That doesn't sound like very protecting. On the other hand, if it was no to any of the above, I don't see many end-user (with low to normal security needs) advantages.

My questions come specifically from this part from the Wikipedia's article:

  Authentication on power up of the drive must still take place within the CPU via either a software pre-boot authentication environment (i.e., with a software-based full disk encryption component - hybrid full disk encryption) or with a BIOS password.

Encryption is handled at low level by BIOS. Every time you power up your PC, BIOS prompts for a password to enable disk access.

Data on disk is encrypted. If you connect an encrypted disk to a different PC, you will see garbage (no partitions at all).

If someone steal your PC, data is safe as it can't be decrypted without password. Almost for sure, robber will wipe off your hard disk to reinstall your pc...

If you PC breaks, you need to connect your disk to a PC with the same encryption system and enter the same password, otherwise you won't be able to read your disk anymore.


Are there any hardware encryption solutions for my notebook? I have a HP 6510b notebook.

Are there any solutions for hardware encryption? I mean I don't want to use software encryption like LUKS, but I don't want that that if my notebook gets stolen the thiefs could get my data stored on it.

Are there any methods, e.g.: a password prompt shows up when I want to boot my pc (even if i suspended/hibernated it)? So are there any "integrated" HDD encryptions available?

thank you.

One of your actions should be to talk with HP's support about this, and hear which encryption solutions HP has validated for this need. Full-disk encryption is common for 'business class' notebooks. You can look into:

Laptop 'hardware' level full disk encryption, via a harddrive that has a built-in encryption engine and the laptop's Trusted Platform Module and BIOS. This can offer excellent performance and simple operation, on the flip side, it generally doesn't protect you when doing a 'soft' close such as Windows's Sleep or Hibernate.
Operating system built-in or pre-OS load software full disk encryption such as Microsoft BitLocker, LUKS, Truecrypt boot disk encryption, or PGP's full disk encryption. Wikipedia has a really nice overview of these.

What you want goes a bit against the common solutions in this space:

You can get 'hardware' full disk encryption, but then you only enter the password when booting up from a full power down.
You could use 'software' full disk encryption such as Microsoft BitLocker, but then that's not "hardware" as you want it.
Or you could leave your boot drives un-encrypted, and have a data-only partition that is encrypted via fx Truecrypt, and is automatically un-mounted when you Hibernate. But that's not full disk encryption, and would by default fx not encrypt your browser history and saved form data.


Monitor websites being visited on network I need to monitor the websites being visited on my wifi network by the different IPs connected to the network. What is the best way to do this? I spent some time with Wireshark but I feel it is a bit overkill for doing this. Is there a cleaner/more efficient way to do this?

The exact answer to this depends on the level of control you have over the wifi network.

Assuming that you can dictate things like proxy servers, then the best option might be to install a forward proxy (something like squid) and then have that do the logging for you.

If you need to know actual URLs rather than just sites, you'll need to set-up SSL interception which involves things like deploying SSL root certs to your clients and also places a large responsibility on you to secure the proxy and certificate infrastructure (failing to do so could impact the security of everyone on your network), so I'd avoid that unless you really need to.


Is it a security risk to remind users of the password requirements at login? I regularly find myself trying to login to websites where I don't remember the password I use. I make some guesses as to what I might have used but usually wind up having to reset it.

One thing that would make the process easier for me would be if the sites reminded me of what the password requirements were. (i.e. if I knew the password needed to be 8 characters, with a capital letter and a number, I wouldn't guess anything that didn't meet those requirements.)

But it seems so obvious to me, so there must be some reason why sites don't do this - is there any security risk to doing this?

If someone wants to crack the passwords for some of your site's users, then knowing the password rules may help him reduce his list of "potential passwords" by pruning out the passwords that the server would not have accepted in the first place. However, if:

the attacker can also register as a user (as is the case for many Web sites, where account creation is free);
the "registration page" already lists the password requirements;

then the attacker can be assumed to already have that information. Hence, it does not harm security to recall them on the login page.

Anyway, maintaining password requirements secret would be difficult, since they have been shown to all users. A secret which is shared by more than 3 or 4 persons is no longer a secret. So it can be assumed that the attacker already knows your password requirements, and displaying them on the login page gives him no extra advantage.

There is a risk that displaying the password requirements on the login page may confuse some users, because such requirements are usually displayed on registration pages, not login pages. You will have to be careful in your wording and presentation. Another possible usability issue is if you change the password requirements at some point, for new passwords: some old, but still valid passwords may fail to match the new requirements, and, there again, the corresponding users may be confused by the mismatch. Yet, these are not security issues (except that confused users are, generally speaking, a potential security hazard).


Using only password to authenticate user (no "username" field) I am creating a client access system, to allow manage invoices, make payments, access information about their products and information/functionality alike.

Supposedly there are less than 1000 clients. Would there be any security threat to use only password (UUID v4 strings) to authenticate user?

My thoughts:

There is virtually no probability of collision or success with brute-force attack. http://en.wikipedia.org/wiki/UUID#Random%5FUUID%5Fprobability%5Fof%5Fduplicates
User friendly (one click go)
It is not intended to be remembered

Main problem with using only the password is that you cannot apply salts.

In a normal, robust server which authenticates users by password, the passwords themselves are not stored "as is" but hashed. The password hashing process requires some care, because an attacker obtaining a copy of that file full of hashed passwords (e.g. through a SQL injection attack) can run a dictionary attack: this is "trying" potential passwords. Human users tend to choose passwords which are "words" in some language, or simple derivatives from that (e.g. appending one digit), hence the term "dictionary".

To make the task harder for the attacker, the password hashing process must:

be inherently slow by mandating, for instance, one million nested hash function invocations;
be salted: the salt is a parameter which alters the way the hashing works, and each hashed password has its own salt value. This way, when the attacker tries a potential password, he must first choose which hashed password he will target.

The username is the selector for the salt: when the server receives the username, it looks it up in its database, obtaining the hashed password and the salt value which was used to compute that hash (both are stored together). This allows the server to recompute the hash, starting with that salt value and the password which the user provided. If the server gets the same hash value than the one which was stored, the user is authenticated; otherwise, the user is rejected. Good algorithms for that are bcrypt and PBKDF2. I prefer bcrypt (but PBKDF2 is not bad).

Without a username, no salt. The server cannot know what salt value to use for the specific password, hence it must use the same salt (i.e. no salt at all) for all stored passwords. This allows the attackers to attack all passwords at once, which is much more efficient.

It is simpler to see it if you think about an online dictionary attack, where the attacker tries potential passwords on your server. With a username+password, the attacker must send a username and a password, and succeeds if the user with that name indeed has that password. Without the username, the attacker just sends a potential password, and succeeds if any user on the system has that password. If you have 1000 users, you just made the attack 1000 times easier.

Also, when a new user registers, he chooses his password. If that password collides with that of another user, then you have no choice but to reject the registration. At that point, the new user just learned that the password he wanted to use is already a valid password for another user -- you just turned the new user into a successful attacker, and he knows it...

Okay, I must remember not to answer question after eating but before the coffee. I just noticed that your "passwords" are actually UUID with 122 bits of randomly generated entropy. In that case, things will be better. We would not call these UUID "passwords", since they are not "words" and are not chosen by a human either, nor even remembered by a human. These are authentication tokens.

You will still want to do your transactions over SSL. Also, since the customers will not remember them, they will write them down, in files or on paper (more probably files, so that they may cut&paste it -- nobody wants to type whole UUID on a regular basis). This makes the secrecy of these UUID more difficult to maintain. Your clients will have to take responsibility for keeping these values secret; this might be a bit too much to ask of a typical client.


Which certificate on my computer is used to make a SSL/TLS handshake When connecting to a specific website(www.test.yyy.com) inside of an organisation SSL/TLS handshake is performed.
From my understanding, I would say that one of my personal certificates on computer is used to validate the encryption/decryption of transferred data.

Now I want to figure out which one is used for that specific handshake, because I would like to transfer it to my second computer (if it is not signed to a specific device*).

FYI: On my second computer I can't access (www.test.yyy.com), because I get error message ERR_BAD_SSL_CLIENT_AUTH_CERT, thats why Iam assuming, that certificate is missing.

Is there any tool or a way to figure out this, I've in mind something like a debugger tool for monitoring HTTPS requests?

Unless you specifically configure your web browser to use a client certificate for the site that you're connecting to, your browser does not use a certificate to make the SSL/TLS handshake with the server.

Instead, your browser receives the server's certificate, and verifies that it was signed using a certificate in your browser's or OS's certificate store that the browser trusts.  There may be one or more certificates in this chain of trust.  You can view this chain by clicking the padlock icon in the address bar of your web browser.  The certificate at the top of the chain is the certificate that your browser trusts, so this is the certificate that you would want to transfer to your second computer.


What is an SSL certificate intended to prove, and how does it do it? If I get an SSL certificate from a well-known provider, what does that prove about my site and how?

Here's what I know:

Assume Alice and Bob both have public and private keys
If Alice encrypts something with Bob's public key, she ensures that only Bob can decrypt it (using his private key)
If Alice encrypts something with her own private key, anyone can decrypt it (using her public key), but they will know that it was encrypted by her
Therefore, if Alice encrypts a message first with her own private key, then with Bob's public key, she will ensure that only Bob can decrypt it and that Bob will know the message is from her.

Regarding certificates, here's what I think happens (updated):

I generate a request for a certificate. In that request, I put my public key and a bunch of information about myself.
The certificate issuer (in theory) checks me out to make sure it knows who I am: talks to me in person, sees my driver's license, retina scan, or whatever.
If they're satisfied, the certificate issuer then encrypts my request with their private key. Anyone who decrypts it with their public key knows that they vouch for the information it contains: they agree that the public key is mine and that the information stated is true about me. This encrypted endorsement is the certificate that they issue to me.
When you connect to my site via https, I send you the certificate.
Your browser already knows the issuer's public key because your browser came installed with that information.
Your browser uses the issuer's public key to decrypt what I sent you. The fact that the issuer's public key works to decrypt it proves that the issuer's private key was used to encrypt it, and therefore, that the issuer really did create this certificate.
Inside the decrypted information is my public key, which you now know has been vouched for. You use that to encrypt some data to send to me.

Is that right? If not, could someone lay out the steps very clearly?

Your key theory: basically right, but authentication is usually done by encrypting a cryptographically secure hash of the data rather than the data itself.

A CA's signature on an SSL certificate should indicate that the CA has done a certain amount of diligence to ensure that the credentials on the certificate match the owner. That diligence varies, but the ultimate point is that they're saying that the certificate they signed belongs to the entity named on it.

See http://en.wikipedia.org/wiki/Digital_signature#Definition


Router administration page is served over HTTP My wireless router admin page does not include https option.

It is always served over http. This is obviously a concern in case someone is sniffing the network and can read my password in plain text.

The admin page is web-based, so I am wondering what a good solution would be.

One idea is to be notified if the settings ever change, what would be the best way to accomplish this?

I am guessing I should set up another device as a proxy between all LAN devices and router and block/allow certain connections? If so, what is the best way to accomplish this?

All suggestions and potential solutions will be of great help. Thanks.

Context: I'm going to assume that you use your wireless router in a home setting. If you use this router in an enterprise setting, get a different router.

Know your threat model!

Obviously, plain HTTP communication is bad. But why? Because it doesn't guarantee the authenticity, integrity or confidentiality of your data. So who could have access to your data? Anyone who can listen to the communication between you and your router.

Depending on how you communicate with the router, the list of devices that can do that becomes very small.

Direct Connection

This is the simplest setup and looks like this:

+----------------+                +----------------------+
|                |                |                      |
|  Your Computer +<-------------->+ Your Wireless Router |
|                |                |                      |
+----------------+                +--+-------------------+
                                     ^
                                     |
                                     |
+----------------+                   |
|                |                   |
| Other Devices  +<------------------+
|                |
+----------------+

It's a wired connection between you and your router. An adversary would need to be able to physically tap the cable to be able to intercept (and possibly modify) your communication between the router and your computer. In most cases, this is an absolute non-issue.

Switched Connection

This is a more complex setup and something you would typically encounter in larger apartments, or in situations where you want more wired connections than your router physically offers.

+----------------+                +-----------------+                +----------------------+
|                |                |                 |                |                      |
|  Your Computer +<-------------->+ Ethernet Switch +<-------------->+ Your Wireless Router |
|                |                |                 |                |                      |
+----------------+                +-+---------------+                +-+--------------------+
                                    ^                                  ^
                                    |                                  |
                                    |                                  v
+----------------+                  |                                +-+--------------+
|                |                  |                                |                |
| Other Devices  +<-----------------+                                | Other Devices  |
|                |                                                   |                |
| (May be evil)  |                                                   +----------------+
|                |
+----------------+

In this example, some devices connect directly to your router (they may be physically close, for example), while others connect via a Switch. In this example, your computer is connected to the router via a switch.

A malicious device, marked here as "May be evil", might employ an attack called MAC Flooding, which targets the Ethernet Switch. The switch would then basically act like a hub, forwarding traffic not only to the intended partner like it would under normal operating conditions, but forwarding the traffic on all ports (except the source port).

This would potentially allow an attacker to listen to your communication with the router's admin page and potentially sniff the admin password.

Is this feasable? This is for you to decide, but I personally would assume that if a device in my home has become infected, I have different worries.

Connection over W-LAN without any Security

This is a situation you definitely want to avoid.

                                                                Unencrypted W-LAN

           ((( O )))                                               ((( O )))
               |                                                       |
               |                                                       |
+--------------+-+                                                   +-+--------------------+
|                |                                                   |                      |
|  Your Computer |                                                   | Your Wireless Router |
|                |                          ((( O )))                |                      |
+----------------+                              |                    +-+--------------------+
                                                |                      ^
                                 +--------------+-+                    |
                                 |                |                    v
                                 | Other Devices  |                  +-+--------------+
                                 |                |                  |                |
                                 | (May be evil)  |                  | Other Devices  |
                                 |                |                  |                |
                                 +----------------+                  +----------------+

Communicating wirelessly without any encryption is the same as yelling any and all of your data at the top of your lungs, constantly. Any script kiddy "advanced persistent nuisance" in your neighborhood who ever watched "üb3rh4x0rZ 1337 guid3 t0 wifi haxxing" can sniff your data, connect to your network, and in general be nasty to you.

Don't do this. Please.

Connection over W-LAN with Encryption

This situation isn't as bad, but potentially dangerous.

                                                                Encrypted W-LAN

           ((( O )))                                               ((( O )))
               |                                                       |
               |                                                       |
+--------------+-+                                                   +-+--------------------+
|                |                                                   |                      |
|  Your Computer |                                                   | Your Wireless Router |
|                |                          ((( O )))                |                      |
+----------------+                              |                    +-+--------------------+
                                                |                      ^
                                 +--------------+-+                    |
                                 |                |                    v
                                 | Other Devices  |                  +-+--------------+
                                 |                |                  |                |
                                 | (May be evil)  |                  | Other Devices  |
                                 |                |                  |                |
                                 +----------------+                  +----------------+

If your "encryption" is based on WEP, then there might not be any at all. WEP is broken beyond repair, and the "advanced persistent nuisance" we spoke about in the last section can crack your key in a matter of minutes.

If your encryption is WPA2-PSK (using AES, not TKIP) with a long, random password and a unique SSID, then you should be fine. The situation is still not ideal, because sensitive data is still transmitted over the air and any wireless device knowing your key could potentially listen to it.

What does this mean? What should I do?

Simply put, connect to your router directly and you should be fine in the vast majority of realistic cases. You will probably not connect to your router's admin page that often, maybe to add a new port forwarding configuration, or to reboot it remotely if the network is bad again.

Other than that, you have the options of using open-source software such as DD-WRT. If your router is supported, then flashing it should be relatively easy. This might void your warranty, so be careful.

Finally, you can just buy a different router. Most stores are required to take it back within a certain period of time for any reason. If you say "the thing doesn't do what I need it to do", then that's reason enough.


Is the OAuth 2 authorization code flow vulnerable to the Confused Deputy Problem? Confused Deputy Problem (also known as 'The Devil Wears Prada') is an OAuth 2 vulnerability arising when the protocol is used for authentication. Essentially, a malicious client obtains a token for a user, and presents this to a second client. If the second client accepts tokens as proof of authentication, than the malicious client can authenticate himself as the user towards another client.

In most explanations of this vulnerability, such as http://blog.intothesymmetry.com/2013/05/oauth-2-attacks-introducing-devil-wears.html and OAuth implicit flow and confused deputy problem, it is suggested that this only works for the implicit flow.

However, wouldn't the authorization code flow suffer from the same problem? It seems that a malicious client can obtain an authorization code for a user, and then offer that authorization code to a second client. The second client now does a backchannel request to the authorization server, and upon completion the second client believes it is communicating with the user rather than with the malicious client.

Is this analysis correct?

In Authentication Code grant flow, the auth server will be able to figure out the auth code was provided to a different client than the second client.

To obtain the auth code, below sample request will be issued from the malicious client:

GET /authorize?response_type=code&client_id=<malicious client ID>&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

Note the auth server keeps a mapping of auth code and client id as a result of a successful auth code request.

Now the malicious client will serve this auth code to the redirect URI for the second client and the second client will in turn request for an auth token. Sample as below:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Note the client ID and secret is encoded in the Authorization header, as a result, when auth server process such information, it is able to tell whether the client id in the request matches to the client id which the auth code was initially assigned to. In this case there isn't a match, as a result the auth server won't grant access token in response to the request.

In other words, the check for client ID performed by auth server in the backend guarantees that all tokens returned in exchange for the authorization code were issued for your application.


Does it make sense to put a firewall within a LAN to protect sensitive information from the rest of the LAN & Internet? I may not be using the appropriate jargon, but I'll try to explain in my own words.

My understanding is that usually a firewall is facing the internet, but my question is about a differnet setup. I'm setting up a terminal at home to interface with my office server which has sensitive information (FYI, its a small business, and I'm the IT person). At the office I have enterprise level dedicated firewall and I'm going to mirror the setup at home. However, I was thinking that it might be more secure to setup the enterprise level firewall within the home LAN such that it isolates the home/work terminal from all other devices in the home LAN. There will be a consumer grade firewall facing the internet. I might be wrong about this, but it seems less secure to have all of my household consumer devices behind the same firewall as my Home/Work terminal that is accessing sensitive information from Office server.

Is this a sensible approach? Is this an overkill, or is there a better way to isolate home/work terminal from household internet devices?

It is a perfectly normal approach to split a network into zones (network segments) of different security requirements and have firewalls between these zones which limit the communication possible between these zones.

It is also perfectly fine to cascade firewalls, like have a firewall from your main network A to the less secure network B and from there another firewall to the even less secure internet. It actually adds security since an outside attacker would need to compromise two firewalls instead of only one (and there are still too many bugs even in commercial systems where a firewall compromise was possible from the internet).

A cascade of firewalls might give you trouble with some applications like VoIP if these firewalls are all doing NAT but from the security perspective it is fine.


How can I remove an unknown device from my wifi network? I have an OnHub (from Google), and there is a device I don't know on my wifi network. Is there some way for me to kick it, or DDoS it, whether through some command line command on windows or ubuntu, or through the OnHub app?

If it can get on now, and you kick it off (rebooting your router would definitely kick it off, for example), it's just going to get on again.

To kick it permanently, do the following, in this order:

Change your router's admin password
Download updates for your router
Disable WPS if it's enabled

ESPECIALLY WPS-PIN (the "enter the digits") because it's ridiculously vulnerable; see Reaver

Change your Wifi to use WPA2-AES
Change the PW to use a long (20 character plus), strong (cryptographically random, like KeePass generates) password.
You will need to change the Wifi password on all your devices, of course, but this should last you for awhile.
Don't give out the new password to anyone.
Don't let them put it in their device; they can pull the password out of their device at their leisure.


Can a captive portal be secured I am interested in using a captive portal on a public network.  After reading the wikipedia article and several questions here on sec.SE, I don't understand how I can secure it, or even, if I can secure it.

The bottom line is MAC and IP addresses are completely insecure.  Without using them, how can I track my clients?

You can generate a session key and store it in a cookie client side which is contains a session token to authenticate the client to the Proxy (yes proxy!). (do make sure it's sent over HTTPS as otherwise it's completely useless)

The proxy does bring a limitation when it comes to other types of traffic such as SSH (taking out of scope that your users know how to tunnel traffic over HTTP). To solve this problem you can step away from the whole 'captive portal' story and try another authentication method like PEAP.

Note that setting up a good way of authentication is not easy as there are many ways of bypassing captive portals. Some are for instance:

DNS Tunneling
ICMP Tunneling
HTTP Tunneling (if you want to disallow
...

Securing these is not easy and not all captive portals can be secured equally well. My preference is EAP-PEAP or EAP-TTLS.


MVC - Dynamic Routing potential security problem? Is dynamic routing as described on https://www.sitepoint.com/the-mvc-pattern-and-php-2/ a potential security problem?

Implementation

<?php
$model = $_GET['model'];
$view = $_GET['view'];
$controller = $_GET['controller'];
$action = $_GET['action'];

if (!(empty($model) || empty($view) || empty($controller) || empty($action))) {
    $m = new $model();
    $c = new $controller($m, $action);
    $v = new $view($m);
    echo $v->output();
}

I wonder if you could do something potentially harmful by just creating objects from user input.

Yes, this is a vulnerability. OWASP calls it Unsafe use of Reflection, and as they state:

  in larger applications where complexity grows exponentially it is not
  unreasonable that an attacker could find a constructor to leverage as
  part of an attack


web app 3rd party JS dependency vulnerability management As a security engineer, I wonder about the common approach for web app 3rd party JS dependency vulnerability management. We have a lot of apps depend on Jquery etc. In a regular vulnerability scan, old versions of JS libraries (which alot of them has XSS CVEs) reported as vulnerability. Without really reading and understanding the code, you can't say your app is affected by those XSS's or not and it is not an easy job for a security engineer. However, upgrading with newer version (which hopefully no assigned XSS CVE s) is not easy too because it requires effort for new developments and QA-UX tests on the app by other teams. I believe it is common problem. So what is the industry standart (applied by big players like Google, Apple, microsoft etc.).
We have cases that we classify the issue as vulnerability, without providing an actual XSS exploit. However development teams are not happy to upgrade it because of the effort. They suggest fixes by editing the library.
So what to do when you encounter an old JS library that has known vulnerabilities?
To Force the upgrade despite to development and test effort?
To fix the old version on your side by looking at the changes over source code? (guess it is the worst idea)
Totally ignoring it until an XSS exploit has been found for that specific app? (finding the real exploit is not easy because the need of really examine where the vulnerable part is and find out if you are using it or not. pretty time consuming for dynamic testers and it is completely manuel)
Classifying them as a risk instead of vulnerability
other ideas?

This is a common issue for legacy systems and not only about JS Library.
Mainly it is a risk and needs to be analyzed, managed, accepted, and documented.
Analyzed
That depends on your risk management process. But mainly, identify the current vulnerabilities with real exploitations so you highlight the real risks for risk owners (the one who is going to accept it). Good to have a PoC.
Managed
Propose the workaround till the risk is remediated... for your case, CSP and other browser-based protection might be a good suggestion.
Accepted
Get acceptance from management (risk owner).
Documented
Document for tracking and follow-up purpose.


is there a way to close 22 ssh port from public, ubuntu? I am using putty and private key to access my development server. I used Nmap online port scanner, to see which ports are visible to the public, and in fact, the 22 is open.
My question is, is it possible to hide open port from the public?
If it is not, how secure is the SSH connection with a private key?
I did the following:

I placed a private key on the USB key (it is not even on my personal computer.)
made configuration you can not log in with "root" username to server.
applied Limit option to port 22 with UFW. (I think potential intruders have only 6 attempts, then they go on timeout)

The 22 is the only port opened. My question is, how safe is this? Do hackers have any chance to get in?

If you connect to the ssh server from only a known set of ip addresses, then it's a wise idea to restrict access to only allow incoming connections from these addresses.  By blocking incoming connections from all other address, this mitigates attacks that may exploit a potential zero-day vulnerability in ssh, or a configuration error.
You can do this in Ubuntu using ufw (uncomplicated firewall).  As root, do the following:
ufw allow from x.x.x.x to any port 22

(where x.x.x.x is the ip address that you want to allow incoming ssh connections from).
Then,
ufw enable

That should do it.  To be sure, run the following command:
ufw status verbose

This should produce:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22                         ALLOW IN    x.x.x.x

Related:
Is starting an AWS instance with only ssh to port 22 significantly insecure?
Logging in to a VPS using ssh and ssh to another VPS using ssh. Does it improve the security of the second VPS?


Developing Android Exploits I have some experience in exploiting. I participated at some CTFs and I have enough knowledge in Linux exploitation techniques. I know Arm and I know how heaps and stacks work.

My aim is to move on Android platform, but the first thing that blocked me is the Tool to use. On Linux with IDA I can make static analysis and with GDb I can make some debugs and check heap layout, stack layout, and register status in order to get a clear idea on how I am manipulating memory.

On Android there is the AOSP and I don't need something like IDA but how can I check the memory layout, registers, and so on (like GDB)? What approach should I use?

To check memory layout and so on you can always use gdb as you did before. For instance, push gdbserver on your device, use adb to forward tcp port used by gdbserver and then use gdb by your side... that's all.

I suppose you get android-sdk and ndk installed


io.fabric.ApiKey. What and why? While decompiling an APK file for Android, I have found an io.fabric.ApiKey key and value stored in manifest file.

My questions are:

Can we use the API key with malicious intends?
Is it ok to be stored in manifest file?

The worst you can probably do is forging analytics data. Then again there's no way to generate a key per install (and even if there was this could be spoofed too). So yes you can abuse it, but the only way to secure it is probably by not doing crashanalytics at all.


Is there anyway to probe open out ports? I can use nmap to find open ports on a specific client with following command:

  nmap -sC -sV [IP]

This command only shows incoming open ports, I'm looking for a similar command to find outgoing open port. For example I want to know whether the client has web browsing access (80) or not.

I imagine there should be a way to send web server traffic to the client and analyze the response and somehow based on that you can determine if the port is open.

Please let me know if there is anyway to figure this out.

For example I want to know whether the host has web browsing access (80) or not.

Outgoing TCP connection (like web browsing) have a source ip and port and a destination ip and port and sequence numbers. In order to get a response from the system your scan attempt would need to match all of these parameters, i.e. you need to guess the (more or less) random port number used by the client and the destination ip the client connects to using this port number and additionally the current sequence number.

Even if you want to know if the client is connected to a specific host you need to try thousands of possible port numbers and up to 65535 sequence numbers. While you've tried this the communication has probably already moved on which means that you now have to guess a different sequence number (i.e. moving target while you shoot). I'm not saying that this is impossible, but very unlikely.


OpenSSL Certificate Expiry I'm trying to use OpenSSL to verify that an SSL certificate is still valid, but I keep getting strange results.
The example site that I'm testing with (expired.badssl.com) has an expired SSL certificate.

Firefox flags this up as expired in April 2015 and shows the relevant warning, but when I look at the certificate information presented using OpenSSL s_client, it says it's still valid until 2016:

$ (echo "" | openssl s_client -connect expired.badssl.com:443 -CApath /etc/ssl/certs/ca-certificates.crt) | openssl x509 -noout -dates
[...]
depth=0 OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.badssl.com
verify return:1
DONE
notBefore=Apr  9 00:00:00 2015 GMT
notAfter=Jul  7 23:59:59 2016 GMT

I suspect I'm missing something here, but I can't figure out what it is.

I think you are missing -servername expired.badssl.com

$ echo "" | openssl s_client -connect expired.badssl.com:443 -CApath /etc/ssl/certs/ca-certificates.crt -servername expired.badssl.com 2>/dev/null | openssl x509 -noout -subject -dates

subject= /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.badssl.com
notBefore=Apr  9 00:00:00 2015 GMT
notAfter=Apr 12 23:59:59 2015 GMT

Apparently this server hosts several HTTPS services...

$ host badssl.com
badssl.com has address 104.154.89.105

$ host expired.badssl.com
expired.badssl.com has address 104.154.89.105

... so the Server Name Indication extension is mandatory to get the appropriate certificate instead of the one corresponding to the default site.


Is there any mechanism to audit which signed certificates are unrevoked? We are currently using EasyRSA and OpenSSL to manage our user VPN certificates for OpenVPN. The process we have in place currently is:

User generates a CSR on their laptop and sends it to us to sign
We copy the CSR to the server, sign it, and return the signed CRT to the user
We usually leave a copy of of the CSR and CRT on the server
When a user's cert is revoked, we store this information in a CRL

I'm tasked with auditing who has access to the VPN. As far as I can tell, the only way we can check who has access is by listing all of the CRTs on the server, and subtracting the revoked CRTs as listed in the CRL. However, this strikes me as not at all sound, as if anyone deleted a CRT and CSR from the server, we would have no way of knowing that it had ever been signed.

Is the current method trustworthy? If not, is there any way to know exactly which certs that were signed are still valid?

Certificates are for authentication, not for authorization.

Authentication is (here) about the OpenVPN server making sure that the alleged client is who they claim to be. This is the point of certificates: the client shows his certificate, which contains his public key and identity; the server validates the certificate (with regards to its trusted CA) to make sure that the certificate contents are genuine; the client demonstrates mastery of the corresponding private key (normally by generating a signature based on a challenge from the server -- this is done within the particulars of the communication protocol). That way, the server learns that whoever is at the other end of the line really is the owner of the public key which is in the client certificate; and the certificate, being verified to be genuine, allows the server to infer that the identity in the certificate really is that of the key owner.

Authorization occurs as a second step. Now that the server knows who is calling, it must still decide whether that client shall be granted access or not. This is a server-side decision.

From your description, you (apparently) configured OpenVPN to use certificates for authorization; or, said otherwise, you apply "automatic authorization" which grants access to anybody who could get authenticated. This is the root of your problem; certificates are not good for authorization. As you noticed, if you use such an authorization rule, then the "allowed users" cannot be reliably listed, unless you keep knowledge of all issued certificates. Also, if you want to close the access for a user, then you normally need to close it now, not within one week; but revocation is asynchronous and will be really effective only when the previous CRL has expired.

While a good CA must retain precise knowledge of all the certificates it has issued (if only to be able to revoke a certificate at will), there is no mechanism in X.509 to ensure the consistency and integrity of such a list. Moreover, the asynchronous nature of revocation is further proof that certificates provide inadequate means of authorization.

What you really need is to maintain an exhaustive list of "allowed users" on the server side (in the OpenVPN configuration files). The users would be identified by their name (apparently, OpenVPN uses the 'Common Name' part of the subjectDN in certificates to reference users); the server will extract the client identity from the incoming client certificates and authorize the user only if it appears in the list of allowed users. If you deploy such explicit authorization, then you have your reliable list of allowed user since, by definition, it is the list that the OpenVPN server uses to grant or deny access. Moreover, it allows you to block and unblock access for any specific user instantly.


How to make sure vulnerability management does not lead to reduced or compromised security When running vulnerability scans, often a particular version of, say, Node.js is reported to be vulnerable along with a recommendation to update to a higher version.  Then we also have insecure SSL/TLS protocols, like TLS 1.0 and SSL 3.0, and it’s recommended to disable them altogether. For me, any of the above recommendations is a change  that needs to be applied to a given application, host, etc.
Now I’m wondering, how can one make sure that any of the changes does not lead to reduced or compromised security? How one can make sure that the new Node.js version is not introducing even more severe weaknesses / vulnerabilities?  How does change management fit into this? In the end, updating the Node.js version or disabling unsecure TLS/SSL protocols is a change request, isn’t it?

Let's take your Node.js example.  You are using a version of with a known vulnerability.  Therefore you have two options:

Stay on the version that you know is vulnerable
Upgrade to a version that may be vulnerable.

The only correct choice is #2.  Is it possible that you are upgrading to a version that also has vulnerabilities?  Absolutely!  In fact that is probably the case, as there is rarely such a thing as bug-free software.

However, the potential presence of unknown vulnerabilities is a red-herring here.  When you know there is a vulnerability (especially when the vulnerability is publicly known), then fixing it is important.  Obviously you don't want to push out a half-baked fix, but staying on a known vulnerable version simply because you are afraid the upgrade may have its own vulnerabilities is definitely a bad idea.


Sample attack scenarios on file downloads over HTTP The websites that serve files over https, can it be considered overkill? or is it a best practice everyone has to follow?

The downside to serving files over HTTPS is that you will lose the caching as far as I've read. But apart from that, the attack scenario I have in mind is either someone accessing the server and manipulating the file which HTTPS doesn't help much to prevent, or someone replacing the file with a malicious one over the air in a MITM scenario which HTTPS can mitigate.

How probable is it to have a MITM scenario where the client goes about downloading a specific executable?

Are there other attacks which HTTPS can prevent?

One other solution some websites use is that they put the checksum of the executable on the website, but most users won't bother to check that or won't even know how to do it.

So to sum it up, is there much gain in serving files over HTTPS (whether a checksum is put on the website along with the file or not) and can serving files over HTTP be considered a huge security flaw?

(The exact scenario in my mind is that a bank is letting the customers download its mobile banking app via its website over http)

It highly depends on the kind of data you offer for downloading and what kind of trust relationship there is between the user and your site. Just take a closer look at what HTTPS offers and what not:

It offers some kind of privacy through encryption. If the data are already encrypted by other means then you don't need another layer of encryption. If the data are for public consumption anyway you also don't need to hide the data using encryption.
It offers tamper resistance. If the data are signed somehow and the signature gets definitely checked then you don't need to add another layer for tamper resistance. Often firmware or software updates are already protected this way.
It offers some kind of authentication of the site which protects against man in the middle attacks. But it offers no protection if the user takes the wrong URL, like a similar or trusted looking URL during a phishing attack.
It offers some kind of privacy to hide which file gets downloaded. But it does not hide the access to the site itself, but hides only the specific URL visited on this site. And it is often possible to find out which file was loaded from the site because of meta data like the amount of transferred bytes.

Which means that depending on the use case HTTPS can help, but it does not offer more protection in all cases. And it offers less protection one might assume. Especially it is still possible to download malware using HTTPS because on either  used the wrong URL (phishing) or the server itself was compromised and serves the malware.

Apart from that it usually does not harm to add HTTPS if you have the resources, no matter if your use case really profits from it. Most users don't really understand the complexities of what https offers and what not but they feel safer with https. Thus you might just give them some illusion of safety, i.e. security theater.


If only SP (or IDP) uses Shibboleth in its SAML implementation, can the systems still communicate? I was reading about Shibboleth's metadata -- https://wiki.shibboleth.net/confluence/display/CONCEPT/Metadata#Metadata-Use(andnon-use)ofMetadata , and how it's used to identify IDPs and service providers involved in the SAML flow.  If a service provider uses Shibboleth, what information does it need to see in its metadata before it will communicate with an IDP?

Further, if the IDP uses the same version of SAML (e.g. v2.0) but doesn't implement Shibboleth, does that mean that the entities can't communicate with each other?

At a minimum. the IdP and SP need to agree on the following metadata in order to successfully communicate over SAML:

entityID's
public keys for message signing/encryption .
protocol endpoints

Typically there are many other elements in metadata, see for example https://en.wikipedia.org/wiki/SAML_Metadata#SAML_Metadata_Examples

User interface elements
Contact information
Registration information
Organization information
Entity attributes for policy configuration, IdP discovery, etc.
Error handling
Requested attributes
etc.

In regard to the second part of your question, the IdP and SP do not need to run the same software (Shibboleth or anything) as long as they agree on the protocol.


Is a random work factor an increase or decrease of security? Assume you use a proven hashing algorithm, like bcrypt with a work factor of 10 or PBKDF2 with 10K iterations. Normally that's really secure already and would give enough security already for most applications.

But then you add an extra element of randomness to it: you generate a random number X between 5 and 15, and you do the normal hashing algorithm X times and store your password once it's done. However, you don't store X anywhere. Instead, when your user logs in, you run the hashing algorithm 5 times, try it, and if it fails, you run the hashing algorithm an extra time and try again, until it works.

Since you don't store X anywhere, anyone wanting to brute-force the passwords will have to do each hashing not once, but between 5 and 15 times, and they don't know in advance how many times they'd have to iterate.

I'm not a cryptography researcher, so I'm not sure to what extent this idea is workable. A subset of users who get a high X might have their UX adversely affected, but the counter to this is that their passwords are slightly more secure. If the hashing really takes too long, you might be able to adjust the original work factor slightly.

I am going to give you two answers, neither of which are information-theoretically correct, either of which should illustrate why not to bother.

Entropy.
Basically, your scheme adds an element of randomness: between 5 and 15 hash cycles. So, any random number X such that 5 <= X <= 15... in other words, X has 11 possible random values... which gives you just over 3.5 bits of entropy.
Even if we call it 4 bits, this is really not a very substantial improvement, definitely not enough to harm UX for it.
Ergo, leave hashing dogs lie.
Attack refinement.
In your scheme, the attacker is aware of your scheme, but simply does not know how many times to cycle the hash. In other words, if he were trying to brute force your hashes, he would first have to hash it 5 times, then hash it 6 times, then maybe hash it 7 times... until worst case he has to hash it 15 times.

So? He'll just aim for hashing it 15 times, and check along the way to see if he could stop early.

What did you just do?
You gave the attacker an easy way out, if the number of cycles was anything less than the maximum.
So why not just give everybody the maximum, and prevent the shortcut?

A more information-theory correct answer might be to point at Kerckhoffs's principle, which basically states that the only secret in a cryptosystem should ever be the key (or, in this case, the password). Not the choice of algorithm, implementation details, number of rounds, etc, none of these should ever be considered secret.
But I think that's just being pedantic here.

And here's another few points to think about:

Don't roll your own.
There is a reason all cryptographers are a bunch of snobs, and it's not their special brand of coffee.
Really, don't try to create your own algorithm, protocol, password scheme, or key management procedures. You won't make it better, and you will most likely make it worse.

On the other hand - DO use what is already well-vetted and considered secure by the best of those who know. Bcrypt (and it's ilk) is pretty darn strong. Want it stronger? Use a bigger work factor. That's what it's there for.


How does Hulu know my local time when I am behind a VPN? To see what would happen, I attempted to access Hulu from a VPN outside the US. As I expected, Hulu detected the VPN. My understanding is that this is because Hulu is aware of the IP address ranges that belong to known VPNs. However, what caught me by surprise was Hulu's ability to display the time of the incident in my local time zone. How can this be possible? How does Hulu know in which time zone I am actually located?

By asking your browser for the current time zone offset, e.g.

var d = new Date();
console.log(d.getTimezoneOffset())

Since I'm in the US/Pacific time zone and it's currently summertime, this returns 420 (7 x 60) for me.

With a bit of additional clever code, it's possible to estimate the exact time zone, rather than just the current offset.


How does Shodan crawl internet-connected devices? I wonder how Shodan crawls internet-connected devices and adds them to its database. I know Google, for instance, finds new websites by following links in websites it already found, but that strategy won't work with internet-connected devices because they don't link to one another.

What method does Shodan follow?

There are only about four billions of possible IPv4 addresses, so trying them all is feasible, with enough bandwidth. There are available tools for that.

Shodan themselves document in their FAQ that they use some custom code:

  A home-grown, distributed port scanner was developed for this project.

"Distributed" here means that connections are made from several machines, which seems not an issue since Internet-wide scanning is, by definition, an embarrassingly parallel problem.

A related case is the so-called Internet Census 2012 in which some unknown people repeatedly scanned for some vulnerable hosts (typically home routers still configured to accept default admin credentials) and temporarily hijacked the said systems to enlist them in a whole Internet scan on "most common ports" -- that's a case of a self-replicating botnet. They say that they reached 420000 clients under their control. For a complete Internet scan, each client only has 10000 IP addresses to try, so this can be done quite discreetly (say, 3 probed IP per second for an hour).


Hide Docker Containers Behind VPN I want to run all services within Docker containers (including RA and site-to-site VPN) such that all containers except the VPN are not exposed on the public IP, but are reachable on the VPN IP. This would mean an attacker would need to gain VPN access to know what was on the network, let alone attack anything. To the outside the server should appear to be running only a VPN server. I know that I can do this by embedding a VPN client inside each container, but I'd like to be able to use off-the-shelf containers and avoid the CPU+MEM overhead that would entail.

I think the most straightforward way to do this would be to use container linking. The exact solution depends on whether your containers that you want to access via this VPN are on different VMs / physical servers or not.

If the containers are on the same server
Essentially you would run your VPN server in it's own container, and link all the other service containers to it. You can then only expose the VPN port on the host machine, but once you are inside the VPN container you'll have access to the other services via docker's container linking private network magic.
If the containers are on different servers
Look into Linking docker containers across multiple hosts - this solution is a little more involved / complicated.


System backup in case of attack? My system will be running for a well known insurance company within the UK, it will hold and process a lot of information for claims, brakdowns etc etc.

I am worried that the company and the site as the site needs to be accesses externally by brokers will be a target for DDoS.

Is there anything I can do within the code that will backup all data if a DDoS attack happens on the server?

I have a feeling I'll just get 'no' or 'yes' answers here if this is the case the what additional security can I put in place to try and prevent DDoS attacks?

Backups don't really have anything to do with preventing or mitigating DDOS attacks. A DDOS attack will prevent people from accessing your site, it doesn't have anything to do with the destruction of data.

So to answer your question, no - I don't think setting up backups will help you in the event of a DDOS attack.  That said, regularly backing up data should be a standard task in any software environment so make sure you are doing that.  In addition to backing up the data - do a mock restore so you will be familiar with the process to bring everything back up after a disaster.

If you are concerned about DDOS give this post a read - it has some excellent information on handling DDOS.


how to null out a insert statement? I am doing a SQLi-Quiz. Below is the orignal statement.

insert into users(name,pass) values('bob', [injection point here])

The statement is heavily filterd because the website which supplys the quiz doesn't want someone breaks the whole database. I can't find any way to get this one done so I search a hint on the forum of the quiz. From the search results I know that the only way to make this quiz done is, someone must nullify the whole orginal query. It means that the value "bob" must be nullified too.

As I know I can't influence the query before the injection point. Anyone has an idea?

You can insert a subquery in place of the injection point. For starters in case of mysql

Select concat(version(),user(),database())
Select grantee from information_schema.USER_PRIVILEGES

Also check out for sql-map tool


When encrypting individual files in directory for cloud storage, is storing IV and salt with the file wrong? I'm developing a simple utility to solve a very specific issue: I want to store all my pictures on cloud. Family pictures, nothing kinky, illegal or death-threatening. the requirements are:

I want them to be at least "obscured", as in "not automatically viewable and indexable when someone sweeps my storage account", like Google or Microsoft when they're collecting stuff to train their cognitive services or any corporation mega.co.nz gives access to my files to. Better would be securely encrypted, obviously.

I need to be able to detect changes to a single image and upload only that, thus avoiding huge archives.

I have developed a sequence of operation using only standard libraries (apache commons crypto mainly) that should be secure by current standards:

[one time, when running the encryption]

input a password (any length)

[next steps are repeated for each file]

generate a secureRandom salt (32 bytes)
compute a 16 byte password+salt hash using PBKDF2WithHmacSHA512 (1000 iterations)
generate a secureRandom IV (16 bytes)
ZIP the single file (this is toggleable as it's useless for images)
AES encrypt the file using AES/CBC/PKCS7Padding

I know that this will not conceal the name, nature and size of my files, (contrary to what Cryptomator tries to do, for example, but webdav is a pain when trying to detect file changes), but that should be fine by me unless it enables cracking of the whole encryption somehow.

Now I need to store the salt and the IV, and currently I have decided to store them in a metadata JSON file in the same place where I will store the encrypted file. I have read and understood that the IV must be random but doesn't need to be secret, correct me if I'm wrong, but what about the hash salt? Can I store it with the IV and the encrypted file without threatening any part of the encryption?

As @Limit commented,

  your entire security is dependent on your password. If an attacker has access to your directory, they can access both your salt and IV.

So it should not be a problem storing these.

Your password is going to be the most important item you need to protect :-)


Relationship between SSL cert database and that at the CA site Say I am using a trusted third party CA site to manage my cert. I created a new cert called CertA at the CA web interface, downloaded the signed cert and use it on my web server. Some time later I found some errors with my web application after implementing CertA. So I saved it's cert.db and key.db and proceed to reissue a new cert called CertB and install it on my web server.

The question now is this: If I want to use CertA again, can I just do it by copying back my saved key.db and cert.db and leave the record at the CA as CertB? OR does it need to be "synced" at the CA as well? That is, my web server holds CertA, and the CA site hold CertA as well.

In short: You can just start using CertA again, until its expiry date, as the CA is not directly involved when certificates are used.

The CA is not directly involved in your use of certificates, unless you revoked the certificate CertA. Revocation means that you go to the CA and explicitly tell them "The certificate CertA was compromised.". There is usually some kind of section on the CA website to do that. They will then revoke the certificate, which means that it announces to browsers that the certificate is no longer secure (through several different means, CRL and OCSP are keywords you want to look for to learn more).

So, assuming you didn't revoke CertA explicitly, you can use it again.

edit:
Note that there are some edge cases where a scenario similar to yours exists, where a specific certificate/set of certificates is identified as the only valid one for a domain or server. If you want to implement this, there are multiple ways to do it (DANE, certificate pinning, and approaches using browser extensions like CertificatePatrol or convergence), but all of them are very much experimental at the moment, and I'd say it is unlikely that this will change in the near future. You can find more information at OWASP and this question on certificate pinning.


Weird IP addresses showing up on my server I have a personal server located in the US, I use it to execute code which requires a lot of resources. I sometimes have apache running on my server, to test php code. I recently left my apache server running overnight, and the next morning I decided to check which ip addresses where connected to my server. To my surprise, I saw a bunch of ip addresses connected via http. Now I have my apache running so only certain ip addresses are allowed to see my directories. Everyone else would get 'forbidden' error, so that's not a problem. So I looked up these ip addresses that were connected to my server, some where from china, malaysia, and other asian countries, one of the ip addresses was google. So I googled my ip address and it was listed in many databases online.

Should I be concerened about this, and talk to my server provider to switch Ip address? Also, are there some bots online that just connect to random servers and sniff open ports or something? is this normal?

This is totally normal. There are thousands of bots on the internet that have the sole purpose of scanning every single IP address and attempting to infect it.  Any information they discover will be put into a database somewhere, and there's nothing you can do about it. If you change your IP then that one will be discovered too unless you enable a firewall like ipchains on *nix and block all but known IPs, which is what you should be doing unless you need the internet to have access to your system.

Also, make sure your system and all the software on it is kept up to date. Be pathological about that as most attacks use well-known and patched vulnerabilities.


Storing LUKS master key in SGX enclave Is it possible to store the master decryption key for accessing a LUKS encrypted volume inside an SGX enclave so that the master key cannot be accessed by any user on the system, even the root user with privileges to make system calls?

Currently, LUKS necessarily has to store the master key in memory that's used to decrypt data stored on an encrypted volume. Therefore, the root user can not only access the drive's contents, but they can also access the drive's master key.

Intel SGX was designed to be able to create enclaves where a machine can run applications such that the host OS can't access the code or data executed inside the enclave.

Is it possible to exploit an SGX enclave in order to store the master key and decrypt the volume's contents such that the host OS can request decrypted data from a LUKS-encrypted volume via the decrypting process running in the enclave, but it cannot access the master key that's stored inside the enclave?

Here's how I understand LUKS works:

A LUKS volume is encrypted by a single key.
A LUKS volume has a number of keyslots.
Each keyslot stores an encrypted version of the key, protected by a (key derived from a) keyphrase.

Do you want to prevent access to:

The key that's actually used to perform the disk encryption.
The passphrases that are used to encrypt the keyslot.

... and what is your attack model; must the system boot autonomously without a user present to unlock the disk, or must some user/sysadmin still provide a passphrase to unlock the disk, so that the disk cannot be accessed after the entire system is stolen?

For 1 above:

The cryptographic operations that implement disk encryption in Linux are typically performed by the CPU itself, in software, in the kernel. In this case, the CPU must have access to the key in order to implement encryption, It is possible to implement kernel crypto drivers that perform the crypto operations, typically in a separate hardware device. You may be able to implement an SGX-based enclave and expose it to the kernel as a crypto driver, thus hiding the key inside the enclave. However, kernel crypto drivers run kernel mode, and I have not seen any way to launch SGX enclaves in kernel mode. That said, I think it's all just software, so with enough resources, you may be able to implement that. Alternatively, perhaps one could run the enclave in user-space, and implement something similar to FUSE/CUSE to allow the kernel to use that user-space application as the backend for a crypto driver.

For 2 above:

Since using the pass-phrase to derive the disk encryption key from the LUKS keyslot is a small self-contained operation, you could probably adapt the cryptsetup application to run that part of the code inside an SGX enclave. This would allow the crypto operations to occur without observation. However, the enclave would still need to obtain the passphrase for the keyslot from somewhere, which in practice means that the kernel has to pass it in somehow, and thus it could be stolen then. Of course, if you're able to set up a trusted (encrypted, etc.) channel between the SGX enclave and some form of trusted input device, so that the channel cannot be snooped or otherwise tampered with, you may be able to transfer the passphrase into the enclave without anything being able to see it.

I guess overall the simple answer is no. The answer may be yes with a significant amount of effort.


Can simply decompressing a JPEG image trigger an exploit? The novel Daemon is frequently praised for being realistic in its portrayal rather than just mashing buzzwords.

However, this struck me as unrealistic:

  Gragg's e-mail contained a poisoned JPEG of the brokerage logo. JPEGs were compressed image files. When the user viewed the e-mail, the operating system ran a decompression algorithm to render the graphic on-screen; it was this decompression algorithm that executed Gragg's malicious script and let him slip inside the user's system—granting him full access. There was a patch available for the decompression flaw, but older, rich folks typically had no clue about security patches.

Is there such a thing? Is this description based on some real exploit?

This was published in December 2006.

Is it sensible to say "the operating system" was decompressing the image to render it?

Note this has nothing to do with security of PHP image uploading scripts.  I'm asking about the decoding process of displaying a JPEG, not scripts taking input from remote users, nor files misnamed as .jpeg.  The duplicate flagging I'm responding to looks poor even for a buzzword match; really nothing alike other than mentioning image files.

Is there such a thing?

Absolutely.  Feeding malicious input to a parser is one of the most common ways of creating an exploit (and, for a JPEG, "decompression" is "parsing").

  Is this description based on some real exploit?

It might be based on the Microsoft Windows GDI+ buffer overflow vulnerability:

  There is a buffer overflow vulnerability in the way the JPEG parsing
  component of GDI+ (Gdiplus.dll) handles malformed JPEG images. By
  introducing a specially crafted JPEG file to the vulnerable component,
  a remote attacker could trigger a buffer overflow condition.

  ...

  A remote, unauthenticated attacker could potentially execute arbitrary
  code on a vulnerable system by introducing a specially crafted JPEG
  file. This malicious JPEG image may be introduced to the system via a
  malicious web page, HTML email, or an email attachment.

.

  This was published in December 2006.

The GDI+ JPEG parsing vulnerability was published in September 2004.

  Is it sensible to say "the operating system" was decompressing the image to render it?

Sure; in this case, it was a system library that required an OS vendor patch to correct it.  Often such libraries are used by multiple software packages, making them part of the operating system rather than application-specific.

In actuality, "the email application invoked a system library to parse a JPEG," but "the operating system" is close enough for a novel.


Is Ubuntu Guest Session safer than Ubuntu Live CD for examining malicious USB drives? I have some allegedly malicious USB drives that I want to test. I have an already installed Ubuntu OS with a guest session and the Ubuntu Live CD. Which environment setup is safer for testing the malicious drive?

Assumptions:

All storage devices will be removed in the Live CD case. In the Ubuntu Guest Session case, there can be other internal drives but not external (internal drives need mounting to be accessed, external drives don't. So the first are not accessible due to root restrictions but the second are).
Network connection is turned off.

NOTE: When I mean safe I do not mean 100% (because that's impossible). A near 100% suffices :-P .

In summary: guest account does not offer lots of protection. Use a read-only or throw away system instead (i.e. Live CD or Live USB) but even this does not offer full protection.

In detail:

Considering the case that the bad USB stick might contain a deliberately corrupted file system which causes a kernel exploit (not that unlikely, see CVE-2013-1773) then the underlying system will be compromised, no matter if this is a Ubuntu guest session or a live CD. Only with the guest account the system compromise is permanent while with the live CD its not, since a CD is a read-only medium. This will be different if you use a Live USB stick which is read-write but even then you could just re-install the stick before you use it the next time.

Even if you don't consider a direct kernel exploit through the file system but just want to execute some potentially malicious code as an unprivileged user you have to take in account privilege escalation attacks like this one which can again result in a compromised system. And even  if you don't want to execute code but just have a look at the data on the stick you might run into bugs like this one where just looking at a directory using some file explorer causes code execution which of course then can do a privilege escalation attack too.

@kasperd noted in a comment that even with read-only medium the BIOS/UEFI or other firmware on the system (like network or graphics card) could be modified to make an infection more permanent. And to add to this: as long as the network connection is only logically off a malware could enable it again and then attack other devices in the system, for example the router. This is especially true when using a guest account since the connection information for the WLAN are usually stored on the system already. But this is also true when using a Live CD but the WLAN is not protected.