Is the developer mode like the opened door for hackers to debug the mobile app? The very good security recommendation is:  the mobile app should check if the developer mode is turned on and it should not start. Both in android and iOS. Do you agree with this sentence? What the development mode is threatened with?
Or what other requirements do you recommend in exchange for this?

No, that's a terrible idea. A few reasons why:

There are a lot of legitimate app developers, and they shouldn't need a separate phone to test their own app than they do to use yours.
There are a lot of legitimate reasons for end-users to use development mode, such as using Helium Backup.
It's really easy for any hacker even slightly more competent than a script kiddie to trick your program into thinking development mode is on when it's not.
If your security model relies on trusting the client, it's as good as broken anyway, and you'd only be giving yourself a false sense of security.


Remote Administrative Access to a server, KVM over IP or HP iLo? We have a situation. We want to grant remote administrative access to one of our servers for clients. As I know, there are two possible ways: 1- KVM-over-IP and 2-HP iLO. The most important thing for us is security. Next we would like to consider other issues like performance and management access levels which we can offer to our clients. Can any one give me a brief comparison between these two methods?

KVM over IP is simply access to physical computer console (screen, keyboard, mouse, USB etc.).

iLO is a kind of remote control interface, using which administrator can control the server below the operating system layer, and even below the physical console, BIOS/UEFI etc.

If you give iLO access to someone, that person will have the complete control over the server. If your customer needs to eg. install his own operating system, it would be completely enough to give him KVM access.


SSL Certificate for use with SSL Inspection on Zyxel USG110 I have a query regarding the SSL inspection functionality on the USG110 series and above. I have a requirement to provide a public Wi-Fi access point, and I’m looking at using a USG110 to provide application control, and content filtering which I can get working ok with HTTP traffic, the challenge I’m having is with HTTPS traffic and being able to use application control and content filtering with this type of traffic to provide protection for the client I’m working with.

I have been able to use IDP to block traffic based on the signature for traffic for example I have been able to block HTTPS to the Spotify website and then with app control also block access to the Spotify desktop application. What I’m looking to do is not have to create a rule for each website or application we want to block through IDP as with the Spotify example it did not block all elements of Spotify and I had to use a mixture of App Patrol and IDP. This is where I’m looking to use the SSL inspection feature along with App Patrol and Content filtering on the USG110 to give me a complete overview of all traffic being passed through the network and apply polices to this traffic.

The query I have around SSL inspection is regarding the SSL certificate, as it is a public Wi-Fi access point I’m unable to control the devices that will connect to this network and thus cannot install the self-signed certificate on to each device so it will recognise any HTTPS traffic that is scanned by the USG as being from a trusted source. If I was to purchase a third party SSL certificate from a certificate authority and then import this onto the USG would this take away the need for the self-signed certificate on the USG to be used, and allow the HTTPS connection to an external source to show as a trusted connection on the devices?

Thanks in advance for your response

Can't be done. Not without you buying a Sub-CA certificate. (Which no self-respecting CA will/should sell to just anybody.)

While there are ways around this, none of them are practical. (And that's a good thing.):
1) You don't care about detection. You just man-in-the-middle everyone, give them an untrusted certificate and hope they will click through the certificate warnings. This is ugly.

2) You don't care about detection too much. You just man-in-the-middle everyone, strip HTTPS and certificates right out (using SSLStrip). Then you won't have to worry about certificates.

3) You care about detection somewhat more and are very, very powerful. You are in a position to have a recognized CA issue an unrestricted sub CA cert for your interception business. This will require the cooperation of said CA. (So this will only be an option if you are a nation-state.) -- Then you will hopefully be found out and named and shamed by Google Chrome. (Which is what happened in 2013: http://googleonlinesecurity.blogspot.ro/2013/12/further-improving-digital-certificate.html )


Multiple tokens support for FIDO u2F I am implementing a web service to support U2F. I need users to be able to register more than one token to their account.

How should the authentication request message look when we have more than 1 key handle?
Currently working with the chrome extension and my working authentication request looks like

{version: "U2F_V2", challenge: "7kozMX4EGFKYqmFOjLPD7QCHyJc7n3Pt0DHigNGf2aU",…}
appId: "http://localhost:8080"
challenge: "7kozMX4EGFKYqmFOjLPD7QCHyJc7n3Pt0DHigNGf2aU"
keyHandle: "nLfGtT8E7EKT5zo9t4zvVPK7qjJQoXqTDD_WHKh64X99LYARhRZc5hb-49AlQYNQcJhkk3ujHeaY5ti9rshrKQ"
version: "U2F_V2"

The JSON for an authentication request containing multiple authenticator (token) key handles looks like this. (challenge and keyHandle values were shortened)

{
  "type": "u2f_sign_request",
  "timeoutSeconds": 30,
  "requestId": 123,
  "signRequests": [
    {
      "appId": "http://localhost:8080",
      "challenge": "7Wr...I6w",
      "keyHandle": "8BB...7YQ",
      "version": "U2F_V2"
    },
    {
      "appId": "http://localhost:8080",
      "challenge": "9Qb...HOE",
      "keyHandle": "5i8...CEJ",
      "version": "U2F_V2"
    }
  ]
}

NOTE: This is for the currently published public U2F Javascript API.
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html

dictionary Request {
    // The type of request, either "u2f_register_request"
    // or "u2f_sign_request".
    DOMString          type;

    // A list of SignRequest dictionaries, one for each
    // token already registered with this RP.
    SignRequest[]      signRequests;

    // A list of RegisterRequest dictionaries, one for each
    // protocol version that the RP is willing to register.
    RegisterRequest[]? registerRequests;

    // A timeout for the FIDO Client's processing, in seconds.
    int?               timeoutSeconds;

    // An integer identifying this request from concurrent requests.
    optional int?      requestId;
};

dictionary SignRequest {
    // Version of the protocol that the to-be-registered U2F
    // token must speak. E.g. "U2F_V2"
    DOMString version;

    // The websafe-base64-encoded challenge.
    DOMString challenge;

    // The registered keyHandle to use for signing, as
    // returned by the U2F token during registration.
    DOMString keyHandle;

    // The application id that the RP would like to assert.
    DOMString appId;
};

dictionary RegisterRequest {
    // Version of the protocol that the to-be-registered U2F
    // token must speak. E.g. "U2F_V2"
    DOMString version;

    // The websafe-base64-encoded challenge.
    DOMString challenge;

    // The application id that the RP would like to assert.
    DOMString appId;
};


Does “emergency mode” help protect iOS devices in AFU mode? In recent iOS devices you can temporarily disable unlocking via biometrics by holding the power button and either volume button for a couple seconds. I’m trying to find out if this does anything to help prevent AFU mode (after first unlock) vulnerabilities such as GrayKey. Does disabling biometrics evict encryption keys (or any other vulnerable data) from memory? Is turning the phone off the only way to prevent AFU vulnerabilities?
Bonus question: What exactly is “partial AFU” as mentioned in this Forbes article?

Once the user activates the SOS mode, the following things happen:

Biometric identification (Touch ID/Face ID) is disabled and the user has to use screen lock code to unlock screen.

USB Restricted Mode is enabled, disabling data transmission over the USB port. If the iPhone is then connected to a computer, the computer will not recognize the device.

There's no current way to force iPhone back to Before First Unlock (BFU) state once the device is already in After First Unlock (AFU) state. However, iOS does evict one set of keys from memory whenever the screen is locked again regardless of SOS mode.
The set of keys that are evicted from memory on screen relock belongs to Complete Protection class of Data Protection API. There are 4 Data Protection Clasess in iOS:

Complete Protection (CP): Encryption keys for this data are evicted shortly after device lock (10 seconds).

Protected Unless Open (PUO): Using public-key encryption, PUO allows data files to be created and encrypted while the device is locked, but only decrypted when the device is unlocked, by keeping an ephemeral public key in memory but evicting the private key at device lock. Once the file has been created and closed, data in this class has properties similar to Complete Protection.

Protected Until First User Authentication (a.k.a. After First Unlock) (AFU): Encryption keys are decrypted into memory when the user first enters the device passcode, and remain in memory even if the device is locked.

No Protection (NP): Encryption keys are encrypted by the hardware UID keys only, not the user passcode, when the device is off. These keys are always available in memory when the device is on.

Only the data that is encrypted by CP is safe at locked screen. CP is a recommended protection but to maintain user experience and to keep user's important apps functional at locked screen, it is not strictly enforced by the app developers and apple itself. Calendar (excluding attachments), Contacts, Reminders, Notes, Messages and Photos are protected by Protected Until First User Authentication class and this is the data law enforcement agencies are interested in.
Spyware agencies have custom tools that can physically extract data from memory without disconnecting the battery. They may not need specific AFU vulnerabilities to extract keys, though it makes the job easier. Android also has SOS like mode called lockdown mode which is opt-in and it is no different. Android doesn't evict keys at locked screen which makes it more susceptible to keys extraction and data decryption.

I asked the author about partial AFU, he said:

I was trying to figure this out too but haven’t gotten anywhere. Current thinking is that it refers to the amount of data they could get, so assuming there’s another form of partial AFU access that allows for a larger extraction.

As far as I know, partial AFU is not a thing. The device can be either in BFU or in AFU. No intermediate state can exist because the change in state is bound to user authentication.

BFU: The device has not been unlocked since last reboot.
AFU: The device has been unlocked once since last reboot.
Android Pie Lockdown Option: a Match for iOS SOS Mode?
How police are breaking phone encryption
Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions


How can I protect a client's mirror of the server's database? The scenario is as follows:

There are clients that users can access and work with.
These clients can be online or offline.
There is a central database on a server, holding all the authorization data.
The clients each hold a mirror of a part of the central database.
At regular intervals, the client go online to connect to the central server, and update its local database to match that of the central server.

The purpose of the local authentication database is that a program running on the client can determine what levels of access users (when the client is offline) are authorized to when running the program.

Are there any general best practices on how to protect the local database on the client from being viewed and manipulated by unathorized users?

Are these (local and central) databases holding authorization or authentication data (or both)? Your question refers to it using both ways.

But, whichever it is, if the database is local and the user (or, equivalently, a process running as that user) has to be able to read it (e.g. to check that they have valid authentication/authorization) and that read has to be (by definition!) before the user is authenticated and authorized, then you are out of luck -- the user will need to have read access so they will be able to read the data.

You may be able to prevent modification of the data (or at least detect and reject such modification e.g. via a cryptographic signature/public key encryption using a private key held on the server whose public key pair is held on the client machine) but the user could still subvert the authentication/authorization within the client application's "offline" mode by modifying/injecting into the locally running code.

In addition to any such "roadblocks" you'll also need to make sure that when the client reconnects, the server prevents any unauthorised changes which were made while in offline mode from propagating to the server.


Shipment tracking displaying delivery information publicly - Is this dangerous? Background:
Many shipping companies (like DHL, UPS, national postal services, etc) will allow the recipient of a package to track their package online, and will often display the address that the package is being delivered to before it has been delivered, and/or the "proof of delivery" with the address of where it was delivered to and who signed for the package. However, this publicly presents the delivery information for every package, and an attacker simply needs to scrape that data.

Questions:
Is this considered dangerous? Has there been any reported/documented "attacks" on shippers or recipients performed by exploiting the delivery information presented by couriers?

Possible Attack:
This thought came to my attention due to an article about how 4,500 marijuana purchasers had their addresses stolen. Basically, people purchased marijuana legally online from a Canadian government website (the Ontario Cannabis Store, or OCS), but an attacker was able to use a Canada Post "tracking tool" to get the delivery information for those shipments. It doesn't explain how the attacker did it, but it's not hard to come up with at least one possible method:

Canada Post (and many other courier companies around the world) allow a shipper to provide a "reference number" with their shipments, which many shippers use as a place to store an identifier, such as the order number, for the shipment. Both the shipper and the recipient can use this reference number for tracking, rather than using the tracking number generated by the shipping company. So what this attacker may have done, was received a package from OCS, noted the reference number and figured out a pattern (eg "OCS" followed by 6 digits), then brute forced the Canada Post tracking tool to try and find a bunch of packages that match (even easier to do if the reference number was an incrementing order number). From there, they were able to get the delivery address and signature of marijuana recipients.

This particular attack was a privacy breach, but it's not hard to see this used for things like corporate espionage (if you can figure out your competitor's reference number patterns, you can start monitoring their shipments and observe who their clients are), or even theft. For example, if you live in a large city, you could find a reference number pattern for a large retailer (say, from an Amazon distribution centre), and monitor all of their shipments. Once you find a shipment destined for your city, you just monitor the tracking to see if it ended up being left in a "safe" place (eg "by the side door"), or if it was signed for by a human...And if it wasn't signed for by a human, the attacker has an address that they can just go steal the package from.

You could, of course, do many other things, like redirect a package to a different address (many companies only require the tracking number and verification of the original destination address, which can be gathered from tracking), or be used to glean information for social engineering. But I'm not trying to create an exhaustive list; I'm basically just asking if this is viewed as an attack vector by any industries (shipping companies or pen testers), and/or if it is commonly targetted. Displaying the destination address and/or the "proof of delivery" seems to be industry standard, and I don't know if this is simply a case of "user convenience" outweighing the potential risk, or if companies just don't consider it dangerous to present this information publicly.

Not if implemented correctly

Information about my package is something that should be only available to parties of interest, which is in most cases the sender and the recipient. I'm excluding the logistics company itself, as they are not using their external API to query this data anyways.

When a new shipment is added to the system, a unique and unguessable identifier, otherwise known as a Universally Unique Identifier (UUID). Here's an example UUID: b5830ea7-1007-4830-9c30-1dd95be968af

The UUID of the package should then be distributed to the sender and the recipient. Forwarding to the recipient is either done by the logistics company, or by the sender, depending on how it is set up.

The only way to access tracking information is by having this UUID. Since the UUID is 128 bits long, the chances of an attacker guessing a UUID at random is negligibly small.

How to not implement correctly

Of course, the far more interesting scenarios is what happens if it's not implemented correctly. I've once encountered a post service, where in order to get access to the tracking information, you had to enter your address and - I quote - "In order to verify your identity, you need to submit your last name". Because, as we all know, last names are very secret information not known to the public in any way.

In general, it's not a good idea to implement a system in which the only method of verification is to query publicly available information. The possible attacks were described pretty well in your question anyways.


Is it possible to perform a MITM attack with a smartphone? Will be possible to perform a MITM attack using a smartphone? If yes, that is very dangerous. Is it really a danger attack?
Shorted : Is possible to perform a useful MITM attack to a victim using a smartphone?

Technically yes, but only in the sense that it's technically possible to shoot down Air Force One with a hand-built trebuchet.

While it's in flight.

Over the Pacific Ocean.

THE DETAILS: The operative word in the phrase "Man in the Middle attack" is middle.

The way the internet - and most modern communications networks - operates is that a message sent from Alice to Bob goes from Alice to Alice's computer to Alice's modem to Alice's ISP to the interconnection between Alice's ISP and Bob's ISP to Bob's ISP to Bob's modem to Bob's computer to Bob.

I'm oversimplifying here; the point I'm trying to make is that said message gets passed through a lot of different systems along the way.

A "Man in the middle" attack happens when at least one of the systems in that path is compromised by an attacker, who can then attempt to read the message, or even redirect or modify it at will.

In theory, it doesn't matter what kind of device you're controlling, as long as it's at some point in the communications chain between Alice and Bob -- hence, "Middle". The trick with MitM attacks has always been to get into said middle in order to do your evil stuff.

So in order for this hypothetical situation to work, your smartphone would have to be legitimately accepted as a link in the communications chain. There are probably ways to do this, but the most obvious way would involve putting out a stronger signal than the nearest three cellular towers so that nearby phones will try to call through yours first... Oh, and you'd have to emulate a cellular tower's communications protocols as well while you're at it...

(Update: A friend of mine points out that windows has pretty horrible default settings in regards as to how it handles USB connections, so if you preload your smartphone with the right malware and then plug it into Alice's computer, you might get somewhere.)


Attacks Against Password Managers What threat models and currently known attacks against online and/or offline Password Managers exist, that do not base on CSRF, XSS or autofill behaviour?

I have found two publications from usenix.org here and here that show detailed explanation for the cases mentioned above.

I would appreciate answers, that are based on current research on commonly used Password Managers (regardless of the Operating System). The threat model or attack may use CSRF, XSS or autofill, but should not be the main attack vector or use an entirely different approach of these, than in the linked papers.

I am open for all suggestions including self-promotion of research. This question is not intended to let you do the search for publications, it is just for answers in case you already know of such attacks and would like to share these information.

There was a presentation at BlackHat Europe 2015 about weaknesses in Lastpass.


Why does LUKS use CBC? I read that LUKS uses 256-bit AES with CBC by default. CBC, of course, has the disadvantages that if you change something in the plain text, you have to change everything that comes after it. In the case of hard drive encryption, that's usually at least a few hundred GB, often several TB. You don't want to rewrite several TB every time a word in a text file is changed, obviously.

I then read that LUKS solves this problem by only using CBC within small blocks (e.g. 512 Byte) which it encrypts independently from each other. Apart from having other problems, how does this not introduce the problems of ECB? Namely being structure-preserving and semantically malleable?

Is a new initialization vector chosen for each of those ~512 Byte blocks so these problems don't occur? If so: How is it chosen?

Why doesn't LUKS use CTR?

Liam Dennehy's answer shows that luks doesn't use CBC by default anymore. As for why it used it instead of CTR before, that's because, under the usual adversary model for disk encryption, CTR isn't secure for disk encryption (as you can see on Wikipedia).

Unless you change the IV on every change, which would require encrypting the entire disk for every change, if your adversary has at some point had the plain text and cipher text for a block, he can decrypt that block until you change the IV, as CTR encryption simply produces a stream of random bytes for a given block which is xored with the plain text. The only way to make it secure without requiring reencrypting the whole disk for each change would be to store an IV per block (which would change for each update), which would be either quite costly in terms of disk space, or would require big blocks and thus reencrypting a lot for each update.

Note that in CBC mode, each 512 byte block has its own IV generated from the key and block number, so two identical blocks will not be the same after encryption.


How Secure Rooted or Jailbroken Devices are? I am just wondering, but how can I harden the security of jailbroken or rooted devices? I understand that SD Card can be still accessible, but how could potential adversaries compromise for example the password lock? Any other precautions I should take or disable some services such as the notorious USB Debigging (adb)? How does iOS and Android platforms compare in terms of what can they expose, should the development/debugging profiles have been enabled?

The problem raises that when an attacker is able to establish a shell or run code on your phone, he has access to all internals. From here he could just unlock the device by overriding commands in the screen lock application or even more easy would be to just start extracting data through the shell.

A problem specifically with jailbroken devices is that you abuse a security weakness to get it jailbroken. The problem is that as long as you don't update your phone, because you want to keep your phone jailbroken, the security vulnerability remains in your device and could potentially be abused by attackers to gain access to your phone.

With android a rooted device is actually a feature, but depending on how you root the phone you need to take care of a few things. Some android rooting programs automatically enable a telnet host without authentication on it. Others automatically enable adb.

The biggest issue is that the sandbox in which your apps run when you have a rooted device becomes obsolete. The App will run as root and will be able to access data stored within other apps. Because of this you become a lot more exposed should you, by accident, install a malicious app.


Understanding boolean based SQL injection I am trying to understand the concept of Boolean Based Blind SQL Injection. I have gone through OWASP Guide To SQLi to understand it. However I am confused with how exactly does it work. Below is what I understand from the article in the above link. Please let me know if my understanding is correct or if I am misunderstanding something.

So as per the link above, we assume a sample URL where the vulnerable parameter is 'id' as:

http://www.example.com/index.php?id=1'

So the coreesponding query being executed on the server could be:

SELECT field1, field2, field3 FROM Users WHERE Id='$Id'

Now assuming that Users contains a field named Username, we want to extract the value of the Username field where id=1 using our boolean technique. So we try to guess this value character by character by doing this:

$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1

The article says that we keep increasing the ASCII value from 97 onwards 1 by 1 whenever we find the evaluation to be false.

  Now the problem here is how to find whether the result that gets returned from the above query is TRUE or FALSE.

So to solve this problem, the article says that we try to perform the following before we try the above:

  $Id=1' AND '1' = '2 so this would generate the query SELECT field1, field2, field3 FROM Users WHERE Id='1' AND '1' = '2'.

After the execution of the above query, the server would return certain status (a page, a redirection etc.). Now since 1=2 will always be evaluated to FALSE, we would get to know what happens in the event of a FALSE result returned from a query.

  Now we can match this result with the result that we get by the execution of $Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1 and thus conclude if the test against 97 (or any specific ASCII value) evaluates to TRUE FALSE.

Is my understanding of the above correct ?
If yes, then in the query, $Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1, why do we need the part after the AND? I mean, can't we confirm the result (as confirmed in the analysis above) without the bold pat of the query? Why is bold part of the query really needed?
Since in this technique also we are basically trying to see the error page and distinguish it from the success page, should it not be considered as an error based SQLi rather than calling it boolean based?

Is my understanding of the above correct ?

Yes, your understanding is correct.

  If yes, then in the query, $Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1, what is the need of the bold part above? I mean, can't we confirm the result (as confirmed in the analysis above) without the bold pat of the query ? Why is bold part of the query really needed ?

For exploiting a SQL injection successfully it is necessary that the resulting SQL is valid. The trailing AND '1'='1 is to fit the injected code into the existing statement. Since we escaped from a string literal with 1' at the begin we need to introduce a new string literal at the end. However, one could also use AND ASCII(SUBSTRING(username,1,1))='97 as MySQL can compare string with integer values.

  Since in this technique also we are basically trying to see the error page and distinguish it from the success page, should it not be considered as an Error Based SQLi rather than calling it Boolean Based ?

Error-based SQL injection would be the case when the server would respond with the actual technical error message like:

  #1064 - You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

Here you can see which portion of the resulting SQL did fail and you may reason how to fix it up with the injection.

In boolean-based SQL injection all you see is just a different behavior on different inputs. This different behavior may include the response of an error message, but unless it’s one with technical details that tell what went wrong it doesn’t help you more than any other boolean behavior.


Are default options of cryptsetup/luks secure? I'm setting up a partition for a linux distribution and I use the command : cryptsetup -y -v luksFormat /dev/sda1.

I believe the default options for the current version of cryptsetup are :

--hash  ripemd160
--cipher    aes-cbc-essiv:sha256
--key-size  256
--offset    0
--key-file  default uses a passphrase
--keyfile-offset    0
--keyfile-size  8192kB

Source

Now I am wondering if the default options are safe enough or if I should modify some for more security. For instance what would be the tradeoff if I changed the key-size to 512 or the hash to sha512 ? Are other parameters worth changing ?

The default encryption options for LUKS volumes are actually:

password hash: sha1
encryption: aes-xts-plain64 with a 256-bit volume master key

For most purposes, the default options are secure.  Three things you might want to change:

--iter-time: This is how long in milliseconds cryptsetup spends hashing your passphrase to create the initial slot key; this sets the number of iterations used in the future when unlocking the volume.  If you're creating your volume on an unusually slow machine, you may want to set this higher than the default "1000" to improve security.

--hash: sha1 has no known weaknesses that would affect its use for password derivation, but you might want to replace it with something like sha256.

--use-random: Some copies of cryptsetup default to using /dev/urandom when creating the volume master key.  The --use-random parameter will ensure that you're using /dev/random instead.


Are the certificates from "skype click to call" and "avast! Web/Mail Shield" any better than superfish? My Girlfriend has a years-old laptop from lenovo.  I checked it over and wasn't surprised that the Superfish / Komodia Root CA certificate was not present.  However I found some others that appear to be similar in function if not purpose.

There's keys which appear to have been installed by Avast anti-virus and Skype, both of which are expected to be on the machine.  However, the puprose of these keys is presumably quite similar to superfish - interception of secure web content by dynamically creating signed SSL certificates for remote sites.

This potentially opens up similar security issues to what was found with the Superfish software.  i.e. if an attacker has these keys they can issue certificates that will be trusted by the local computer.

1). If I understand correctly, in order for these programs to play MITM, they need to have access to the private key associated with the installed cert authority.  So it can be obtained by reverse engineering the sotware.  Correct?

2) Can anyone confirm whether or not these keys are individually generated for each installation?

My understanding is that Superfish installs the exact same certificate and private key into every computer, so once you obtain the hard-coded private key you can use it to man-in-the-middle anyone who has superfish installed. Avast does not do this; it dynamically generates a unique certificate and private key for every install.

This is what the Avast certificate on my desktop looks like:

And here is the Avast certificate on my laptop:

So clearly, they are different certificates. This means I cannot just grab the Avast private key from my own computer and use it to attack someone else who has Avast installed. The same cannot be said for superfish.

Another difference is that Avast does not just blindly man-in-the-middle everything. Instead, it first verifies the validity of the original certificate. If the original certificate is valid, it will proceed to man-in-the-middle the traffic so it can scan for malware. But if there is a problem with the original certificate, it will intentionally man-in-the-middle with a certificate NOT installed in the trusted certificate list, generating a browser warning. You can see this working in the screenshots below:

When visiting a website with a valid certificate, Avast MITMs the traffic to scan for malware...

But if I visit a site with a self-signed certificate, Avast will intentionally MITM with an untrusted certificate to generate a browser warning - notice the name "Avast Web/Mail Shield UNTRUSTED root"

This way, Avast avoids accidentally causing a user to visit a website with a bad certificate. It's not perfect, but it's still a lot safer than blindly man-in-the-middling everything, with a root certificate that is identical and trusted on every computer like Superfish does.


How do dissidents use Tor? The most common justification for Tor is that people in countries like China that don't have full protections on free speech can use it to publish dissenting opinions or access foreign information. I don't understand how this protects them. Even though their governments cannot tell what information they're publishing etc, if the government is monitoring their internet connection they can still see if they are using Tor or not, and that is enough to compromise the dissident. So why is this considered a justification of Tor?

It may be your English skills, but TOR does not need a justification.  TOR was invented by the U.S. Naval Research Labs and the U.S. DARPA (see Wikipedia History) as a research project.  However though part of the U.S. Military, they publicly released the concept and its code, then a non-profit (the TOR Project) continued to develop and expand it.
TOR has many potential use-cases (not justifications).  Since at a 10,000-foot level of abstraction, it is essentially a multi-hop VPN, its most trivial use-case is to use it in situations where a public and free VPN would be useful (such as when using a free and open WiFi in cafes, airports, and hotels), but no VPN is available.  TOR is slower than a VPN, so its not an apples/oranges comparison of usefulness.
However, one of the stated project goals of TOR was to provide a level of anonymity of routing over the Internet (originally) from the client-side against a form of forensics/ investigation called "traffic analysis".  The concept was that even though the Internet packets were in-the-clear once it left a TOR exit node, those packets could not be traced back to the client-side originator.

So one possible use-case was that dissenters could use TOR to get past country-level firewalls to access foreign Internet resources.  Or use TOR within a country, knowing the country would see the traffic past the TOR exit node, but could not determine who actually sent it.  Of course that left the recipient of that traffic exposed.
So TOR was extended to allow for "hidden services", such that in the dissenters use-case, an TOR email server could be setup as a "hidden service", and both parties use that email server via TOR to send and receive private emails between them.  In that case the dissenters traffic never "leaves TOR", and the country never has an opportunity to see it in-the-clear.

However, both the original designers of TOR and the current sustainers of TOR really did not take into account what happens when the underlying network infrastructure of the Internet is totally eavesdroppable by country-level agencies.  Even though the TOR Nodes fluctuate, agencies of various countries have "mapped the TOR nodes" and remap it continually using TOR's own tools.

It is now possible for certain countries to know which clients and servers (by IP Address) have accessed a TOR entry node.  Indeed, network logging by ISPs, companies, and organizations (in this example a university in the U.S.) allow them to also know when clients and servers within their networks access a TOR entry node.

And of course, a country-level firewall can block all access to known TOR nodes that are outside their country, be they acting as entry, relay, or exit nodes.
There are even more recent developments that again have weakened the effectiveness of TOR, at least against country-level agencies.  These include Deanonymizing, bugs in TOR Browser,  TOR Hidden Services malware, and more.  However, the TOR Project is attempting to improve TOR to eliminate these new and advanced vulnerabilities.
So TOR today is still a possible technology that dissenters could consider using.  But like all technologies it has ever increasing risks in using it to achieve anonymity.  However, those risks vary by country in which a dissenter resides, depending on the Internet sophistication of the country's intelligence and investigative agencies.
If as in your question's scenario, the dissenter is already a "suspect" and his or her Internet connections are being eavesdropped upon already.  So TOR is neither helping or hurting that dissenter's anonymity; the dissenter is already exposed.

TOR would still offer confidentiality in the dissenter's use of the Internet, but so equally would a VPN, or using a web-site that uses TLS (though there are separate attacks against both VPNs and TLS).
And given the malware the country may be able to inject onto the dissenter's computer, their use of TOR (or VPN or TLS) may only give the dissenter a false illusion of continued anonymity and confidentiality.
And like that classic OPSEC tale of huge uptake of pizza deliveries to the Pentagon signals an imminent operation, indeed the use of TOR in particular (since it is not as common as TLS or VPN use) could trigger those monitoring authorities to assume the dissenter is actively up to no good.


Encryption - RSA vs. AES I have a question regarding encryption and whether to use symmetric or asymmetric encryption.

The idea is to implement a form of data encryption in a variety of software. This data will be exchanged with third parties, who will verify it. The main objective is to ensure the integrity and authenticity of data. Exchanging keys securely is not an issue.

The question is:
Is it best to use RSA (along with a hash function such as SHA-1) or AES encryption to protect the integrity of the data? What are the pros and cons with regards to the following factors:

Difficulty of implementation. Is there any difference in how difficult it is for a developer to implement (code) RSA and AES?
Computing power. Does RSA or AES require more in terms of computing power and speed in order to encrypt/sign the data?
What are good key sizes? 1024 bit RSA / 128 bit AES?
Any other factors to should consider when choosing the type of encryption?

If your main objective is to ensure integrity and authenticity, and not confidentiality, it sounds like what you want is not encryption, but message authentication (symmetric, like HMAC) or a digital signature (asymmetric, like RSA).

Since you mention third parties, it's likely that signing with an asymmetric system should be used, since with a symmetric system the third parties would be aware of the key, and could impersonate the authentic sender (perhaps you).

Implementing (coding) RSA or AES even from the ground up isn't difficult per se, but it's difficult to do correctly. Use some well-known library or an application to do it. (For signatures, you could use e.g. GPG.)
RSA is (much) costlier to compute in terms of ciphertext bytes than AES, but the usual method is to use RSA to encrypt a symmetric key, and to encrypt the message with that. Or with signatures, to sign a hash of the message (instead of the message by itself).
For key sizes, a 128-bit AES key is considered to correspond approximately to a 3072-bit RSA key. 1024 bits for RSA is on the low end.


How do anti-viruses identify malicious pages when JavaScript doesn't have access to the filesystem anyway? Disclaimer : I am not very knowledgeable about the behaviour of anti-viruses (anti-viri?).

I was wondering how they discern between malicious and non-malicious pages if all they can read is the HTML and JavaScript.

Do they just have a list of sites that are deemed malicious that are updated? If it has .exe downloadable files? How?

HTML and JavaScript, when employed in specific ways, can be used to o wn your system, even your home router. The attack vectors against a web browser involve things like:

malicious plugin files (mainly Flash, Silverlight) that exploit vulnerabilities in the plugin (Flash Player, Silverlight Player)
JavaScript that exploits vulnerabilities in the browser's JavaScript engine
XSS attacks that attempt to fool the user into giving up credentials to another web site (e.g. banks, PayPal, etc.) that the attacker can use for financial gain.

Anti-virus programs that protect browsing sessions look for and quash known exploits like XSS and malicious plugins. If history is any guide, there are always unreported vulnerabilities, so there are always opportunities for hackers.


Modeling & Simulation: Do vulnerability-scanner software simulators exist? In my research, i am attempting to develop a simulator that mimics the output of a vulnerability scanner, given a set of parameters (e.g., Network IP ranges, number of machines to scan, typical machine configuration, etc).

do these types of simulators exist?

Why don't you just set up a virtual machine, with a virtual network, and run a real vulnerability scanner inside the virtual machine?  That will generate realistic traffic: it's not a simulation, it is the real thing.


Are there significant security risks in trusting randomized subdomains to run JS? This question is similar to Is it safe to whitelist CDN domains?, but is focused on the user's perspective.

It seems common in American business websites to use a CDN that presents partially random subdomains to load Javascript for core functionality. The most common example I find is <somehash>.cloudfront.net.

Users with a domain name-based blocker like NoScript have a usability/security problem here: They need to load the JS from the CDN domain, but the domain name isn't memorably or deterministically (from the user's perspective) linked to the site. So it's difficult for them to verify whether or not that subdomain is providing trustworthy JS for that site, especially if its source is subject to change.

So what's a good habit for a user here? Trust on first use? When the hashed subdomain changes, what do they do then? What are the significant risks here?

Ideally, sites will use subresource integrity mechanisms, as described by the w3c

This will allow you (well, ideally your browser on your behalf) to verify that you are getting the file you expect from the content delivery network, by verifying that the hash matches the expected one, as defined in the main resource.

If they do not, you are probably out of luck - your 'trust the first time, investigate if it fails to match the next time' is probably as good as you get - that's why they created this standard.


Trying to replicate SQL injection attack OK so I have a classic ASP website and it recently was victim of some SQL injection where some tables where updated. Nothing seriously happened as for I don't keep anything personal in the database. I've researched a bit and can seem to find an answer to my question.

So here is what i have found so far. I have the URL to my website (not the real one)

www.myWebSite/default.asp?pg=buy&Id=1

I can simply write an UPDATE query as such

www.myWebSite/default.asp?pg=buy&Id=1; UPDATE table SET col WHERE something here.

This will update the database and such but that's if you already know all the tables names.

So this isn't ideal at all. My question is: how do i get all the table information? I've tried to get errors to be thrown and do anything I can find online but nothing seems to show.

There's a lot of ways to get information out of databases through SQL Injection (similar techniques can work for other injection avenues as well).

First, there's error based - you deliberately create invalid request and the webpage helpfully hands you back a full SQL statement with what's wrong with it.  You can use this to guess table names and confirm whether you are right.  This one only works with websites that are not properly configured - 500 (server error) pages should NEVER return debugging / stack / database information, ever.  That data should be logged and a friendly, non-specific message should be given to end users.

Second, there's taking advantage of queries that display data.  If you've got a page that is displaying rows of data, the attacker can tack on a Union and another select, guessing the number of columns that the query is expecting (you can do this by trial and error) and the database tables that provide table/column data.  This will provide them all the tables and their columns and they can use that information to extract further information or do damage with updates and deletes.

Third, if you can't actually get any data out (because the only injectable statement doesn't return any data (an update for instance), you can do what is called Blind SQL Injection.  You can cause the database to leak information just by its success and failure - you can guess table names and see if the update succeeded or failed.  You can even guess column values and use that to leak data - is there a user whose name starts with a? b? that the second character is o?  that the third character is b?  Oh, there's a user named Bob.  Obviously, this is best scripted, since leaking quantities of data this way takes a LOT of requests, but not as many as you might think.  Blind SQL Injection can also be done timing based rather than error based - basically if a condition is true, they put a sleep in and use the difference in the query execution time to determine if the condition was true or false.

Hopefully this will help you find more information on each of these.  There are likely variants and other techniques that I am not familiar with - my role is not primarily pen-testing, but rather secure software development practices.


SSL certificates using modern cipher suite vs obsolete cipher suite I am shopping around for a SSL certificate and I took this screenshots from Chrome

and

Is the second site certificate showing errors less secure than the other not showing errors?

There are two different security information shown: about the certificate itself and about the encryption algorithm. The second part (i.e. "obsolete cipher suite...") is independent from the certificate and depends on the setup of the server.

But the first part is about the certificate itself. The main difference here is that the first site uses a certificate from a CA supporting certificate transparency while the second site does not. This means that the first CA is more transparent about the certificates it issued than the second and thus can be more trusted. Certificate transparency is (at least with Chrome) for now primarily required for extended validation (EV) certificates. But in the future Chrome will probably require it for other certificates too.

Another difference in the certificate part is "Unable to check whether the certificate has been revoked". Chrome only checks selected certificates for revocation, like the EV certificates and some others Google thinks are important. Obviously the certificate for the second site was not important enough to get checked against revocation and thus the certificate can be considered less secure, at least within the Chrome browser.

And finally the information for the first site show more information about the site you visit, while for the second site you got no information except who signed the certificate. This is because the first certificate is an EV certificate where the CA checks business information etc to verify the identity of the owner. In contrast the cheaper domain validated (DV) certificates check only if the party owns the domain, by checking if it is has access to specific mail addresses or can create specific files on the server. This is much more easy to spoof and thus these certificates are less trustworthy.

Of course, most clients don't understand all of these anyway but they might understand the difference between a reassuring green bar for EV certificates and only a small indication of security for the other certificates. At the end it is easy for an attacker to get a DV certificate for its own site. But it will be much harder to get an EV certificate because of the additional verification procedures.


Understanding Session Fixation Vulnerability What I've Read

I'm read the following resources on session fixation, but I'm still having difficulty understanding some aspects of this kind of vulnerability:

Ruby on Rails Security Guide § 2.7 Session Fixation.
Preventive Measure for detecting Session Fixation attacks.
Session fixation attack.
Wikipedia: Session fixation.

Let's assume that sessions IDs are server-generated, and that they're stored and accessed from cookies, not passed around via GET and POST requests. The Rails guide in link #1 above describes the attack like this (summarized from source, emphasis mine):

  The attacker creates a valid session id: They load the login page of the web application where they want to fix the session, and take the session id in the cookie from the response (see number 1 and 2 in the image).
  They possibly maintains the session. Expiring sessions, for example every 20 minutes, greatly reduces the time-frame for attack. Therefore they access the web application from time to time in order to keep the session alive.
  Now the attacker will force the user's browser into using this session id (see number 3 in the image). As you may not change a cookie of another domain (because of the same origin policy), the attacker has to run a JavaScript from the domain of the target web application.
  The attacker lures the victim to the infected page with the JavaScript code. By viewing the page, the victim's browser will change the session id to the trap session id.
  As the new trap session is unused, the web application will require the user to authenticate.
  From now on, the victim and the attacker will co-use the web application with the same session: The session became valid and the victim didn't notice the attack.

What I Don't Understand

Now here's the part that I don't understand. Leaving aside the fact that an effective counter-measure against this attack is to simply issue a new session ID to the victim user when they login to the legitimate site, why does the legitimate server require the victim user to login anyways, even though they already have a "valid" session ID?

After all, the attacker has been maintaining the validity of the fixed session ID beforehand (as pointed out in step #2 in the Rails security guide quoted above), so why wouldn't the server just accept the session ID and log the victim user into the website as the attacker? Why are login credentials required again?

Note that this question is not specific to Ruby on Rails. It applies to any implementation of user sessions, in any framework and language.

The attacker never logs into the site with their credentials, they just access a page to get the session id, so while they pass on a valid session id to the victim, they do not pass on an authenticated session. When the victim logs into the site, the session is now authenticated and the attacker can access it as the victim.


How significant is the risk in having someone email/IM an htpasswd hash? I need to set users up for subversion access, and we're currently stuck using htpasswd for our credential storage. If a user sends me an htpasswd record via email (or GChat / off the record?), what's the level of risk we're incurring?

Hashing would be done using the default htpasswd algorithm: htpasswd -n someuser

And some users would likely be generating their hashes with this tool: http://www.htaccesstools.com/htpasswd-generator/

So, there are three risks I'd like a professional opinion on. The risk or likelihood that ...

.. htaccesstools and/or the connection between the two is compromised and that the attacker can guess what the credentials will actually be used for!
.. the IM/email will be compromised.
.. if the hash is known, that it can be cracked. (If we can assume the users pick strong passwords, what level of risk does htpasswd's default hashing (md5?) impose?)

But maybe more importantly, would a security-minded professional in my situation prefer this route? Or would he just pick passwords and tell the end-users their passwords over the phone?

By default,  the htpasswd utility tends to use an Apache-specific hashing password called "apr1" and documented here. It seems to be a custom construction that invokes MD5 1000 times. Assuming that there is no structural weakness in that construction, the attacker can still try out passwords at a rather fast rate. As documented here, an AMD R9 290X GPU is be able to compute about 11.5 billions of MD5 per second. Since each password try requires a thousand MD5 invocations, the attacker should be able to try 11.5 millions of passwords per second. This is quite fast, and one has to assume that a "normal user password" won't last very long.

Even a rather strong 44-bit entropy password will fall within a week of computations, with an attacker using a single off-the-shelf GPU.

Function identification is not hard since it is written in the hash string itself (e.g. it begins with $apr1$).

Personally, I'd use the phone. As @André suggests, PGP is also usable, provided that PGP is installed. Another option is to open an SSH-based shell account (this requires obtaining a copy of the SSH public key of the user) and storing the password in a file on that account (or the user pushes his htpasswd file there).

Emails may be fine if you can control the whereabouts of the email, which is hard in all generality, but can be made much easier in some cases. Namely, have the user send the email from his gmail account to your gmail account; presumably, emails sent from gmail to gmail don't travel unprotected over the Internet. However, since there is no security whatsoever in the email protocols, such an assumption cannot be made for just any email server.

(As a rule, it is better to assume that any attacker who bothers reading your emails knows quite a bit about what you do and what exchanged passwords are for -- after all, he reads your emails.)


SSL to web server from Cloudflare Hey I have Cloudflare protecting my website. I had a Let's Encrypt SSL certificate encrypting it before. If I send a request and it passes through Cloudflare.

When it gets to my web server will it be secured by the Let's Encrypt SSL certificate?

From Cloudflare Support - SSL FAQ:

  What do the SSL options mean?

  Your domain's SSL option determines how Cloudflare connects to your server either using encryption or not.

  Flexible SSL:

  SSL is terminated at the Cloudflare edge servers. Everything between your client and Cloudflare is encrypted, but between Cloudflare and your origin server is not encrypted. You would not need a certificate directly installed on your server for full encryption.

  SSL Full:

  SSL is terminated at the Cloudflare edge server. Then it is encrypted again, and sent back to your servers all encrypted. You would need an SSL certificate installed directly on your server for this option. You can also use a self-signed certificate for this option.

  SSL Full Strict:

  Same as SSL Full, but you must have a trusted certificate that is signed by a valid Certificate Authority (such as GlobalSign or DigiCert).

  Custom SSL (Business/Enterprise ONLY)

  Customers on these plans are able to upload their own SSL key and certificate, so CloudFlare's name will not show if a visitor checks the certificate.

So as long as your domain is using the "SSL Full" or "SSL Full Strict" option, the traffic should be encrypted from Cloudflare to your server.

To set this option, go to the Cloudflare Dashboard for your domain, select the "Crypto" panel, and change the SSL Option from the default of "Flexible" to "Full (strict)". Since you're using Let's Encrypt on the origin server, strict mode should be acceptable for you.


User accessed Phishing link but didn't provide the credential but got hacked? One of my colleagues received a phishing email in which he clicked on a link. The domain (www.phishing-link.biz) redirected to adfx.xxx.edu which does look like adfs authentication page.

Colleague restated that he did not provide his user name and credentials but closed the window immediately. But after several hours later his account got compromised and huge amount of spam emails were flowing out.

Without providing any information, is there any way the hackers get the info (like session hijacking).
From host level, how can we see that the user has not provided credentials. Is there any tool which can assist me in getting info?

I see that the site is now suspended by hostmonster. Assuming he did not provide credentials knowingly or unknowingly, here are a few possiblities, if the phishing email was linked to the account compromised at all.

1. Clipboard content stolen

The malicious page could have stolen clipboard data.

2. Malicious scripts

The malicious link redirects user to an edu page, but in between the redirection could be many other redirected pages. I've seen a few good examples going through different server-side php pages (apart from client side code from above example) and it's transparent to the naked eye. Scripts could send out emails without email client dialog boxes.

Malware could have been downloaded as well, that may have compromised the machine to be an open relay server.

3. Malicious plugin/extension installed

In basic authentication, credentials are sent via HTTP POST, which is accessible via browser developer tools. A malicious plugin can exploit that.

With that said, it is useful to understand how the spam emails were sent out, be it through web mail (so we know it's about web security) or client-based (so we know it's host and network security related). Each track would have more possibilities of their own.

In terms of tools that can help you, why don't you check on outbound data to the malicious host, if you have the logs - proxy logs, netflow, packet capture etc.
Those would paint a good picture on what was ex-filtrated.


Is possible ot create XSS with theses chars? As part of bug bounty, I have a PATCH request to the API to change my name.
I can post theses chars:
:
;
'
*
`
=
#
/
[
]
(
)

This is the HTML result :
data-cy="label-input__input" value="My injection :;'*`=#/[]()" class="label-input__input" data-v-71bcf264> <!---->

Am I obligated to use the char " to inject my JavaScript ?
I already visited the page : XSS payload without - &<>"=() but the following code doesn't works:
javascript:alert`1`

No, not in the context you have here.
URIs like javascript will not work in a value attribute, so you'll need to escape that context. You can only do that with ", which you don't have.
With the limited characters you do have, you'd either need an injection where you can use javascript URIs (eg into href), an injection into an attribute value context enclosed by ' (or not enclosed at all), an injection into a JavaScript context (eg a javascript variable enclosed by '), a bypass of the filter (maybe via some encoding, though unlikely), or insecure handling of the value via JavaScript (eg the input being passed to eval).


What is the security vunerability in this scenario? I saw this question:

  Suppose a university with address block 12.1.0.0/16 has a link
  connected to AT&T, where the AT&T router forwards packets destined to
  12.1.0.0/16 to the university router.  Suppose the university router has three forwarding entries: 12.1.1.0/24 out the link to the math
  department, 12.1.2.0/24 out the link to the CS department, and a
  “default route” for 0.0.0.0/0 pointing to the AT&T router.  Suppose a
  host in the rest of the Internet sends a packet destined to
  12.1.57.109.  What would happen to that packet?  What could be done to prevent it?

the answer is :

  The packets would loop between the AT&T and university routers,
  because AT&T would forward the packet to the university (using the
  route for 12.1.0.0/16) and the university would forward the packet
  back to AT&T (using the default route 0.0.0.0/0).  The university
  should configure a “null route” to drop all packets matching
  12.1.0.0/16 to prevent this.  See http://www.nanog.org/mtg-0602/gao.html for details about this issue,
  and the security vulnerabilities associated with it.

I can't understand what are the security vulnerabilities associated with it

all above taken from http://www.cs.princeton.edu/courses/archive/spring11/cos461/exams.html

You could start sort of a DoS attack by sending packets to out of range 12.1.0.0/16 addresses that would get stuck in a routing loop. Eventually you could get enough traffic in the loop that things would start to break.

So their inbound filter would look like this

12.1.1.0/24 allow
12.1.2/0/24 allow
12.1.0.0/16 drop


Is a handwritten scanned signature equivalent to its paper counterpart? In terms of Authentication, Integrity and non-repudiation, is a handwritten scanned signature equivalent to its paper counterpart? For example, if you have a paper contract and you obtain a digital copy of it by scanning it, both are equally valid in a court in the event of a conflict?

If not, what are the minimum measures the digital copy need to have to ensure at least the same validity?

Note: I'm more interested in the case of a captured handwritten signature using a tablet or similar, but I think the example is better with the scanned signature because you obtain two versions of the document signed using different tools.

Authentication, Integrity (?) and non-repudiation are digital infosec terms, and what you want are the electronic terms.

Are you in the United States?  The American Bar Association has extensive guidance on this.  Try Digital Signature Guidelines: Legal Infrastructure for
Certification Authorities and Secure Electronic Commerce for some basic information (the front talks about scanned wet signatures, but the rest of the document is a 'must read' for the use of digital signatures, which is related but off topic.)


With DNSSEC, is there any benefit in DANE for a CA- issued Cert? I just deployed DNSSEC at val-id.com and getvalid.com

Since DNSSEC is a requirement of DANE, and I have a CA-based certificate, can I show my support for DANE-based deployments by publishing my CA-based cert into DNS?

My concern is consistency in the client.  If there is an attack on DNS vs a compromised root, how will each client respond?

Well, DANE can, in conjunction with Public Key Pinning' (HPKP),  protect your current users from malicious use (even if the DANE record changed, the browsers will still remember the HPKP headers and fail to connect). This does not protect new connections. But since HPKP has a life of at least 1 month it adds reasonably safety to your 'stack'.


Can any of the INTEL-SA-00086 vulnerabilities be exploited by an unprivileged user? Several of the latest Intel Management Engine vulnerabilities are listed as local vulnerabilities, allowing code executing on the system to elevate its privileges to ME context. One of them (CVE-2017-5708) claims it allows an unauthorized process to access privileged content via unspecified vector. This gives no hints as to what is required to exploit it. I am specifically curious about the privilege escalation or information leak vulnerabilities.

To the best of my knowledge, on a system running the ME, assuming AMT is unprovisioned, userspace can only interact with the ME via HECI. This requires privileged instructions, so it can only be done by the kernel (or root via the kernel). Can any of these vulnerabilities be exploited entirely in userspace, using only unprivileged instructions? This is what makes the difference between this being really nasty, but overblown, and this being a full-scale disaster.

The CVSSv3 vector scoring says that CVE-2017-5708 requires "low privileges" (PR:L), but gives no further details (while a Cisco advisory says the attack requires access to a privileged user). The same is true for CVE-2017-5710, but that one is an exploit against Intel TXT, which, to the best of my knowledge, only adds privileged instructions.

Could a low-privilege process running as an isolated user exploit any of these vulnerabilities to gain higher privileges or read valuable information, assuming no vulnerabilities in the kernel, and assuming the MEI and TEXI drivers are not present? A few sources like The Register seem to explicitly say that a high privileged process can exploit these vulnerabilities, but they do not explain where they got that information from. According to the CSSv3 specifications document, PR:L is designated for attacks that require only basic user privileges, whereas PR:H requires "significant" privileges, such as administrative privileges. This makes it seem like the attack works as a regular user, in ring 3, but it conflicts with the other sources above (as well as my limited understanding of the methods of communication with the ME).

According to one of the people who discovered one of these vulnerabilities, the vector lies "somewhere in between" access to /dev/mei0 and access via a flash programmer. I'm not sure if he is implying simply that the vector is different, or if it requires more privilege than access to the character device, but less than that provided by physical access and a flash programmer. A discussion on IRC revealed that the original vulnerability may be related to improper configuration of the P2SB PCI bridge on Intel Series 100 chipsets (the Skylake PCH), but the specific implications seem ambiguous (not to mention, that is for only the first vulnerability disclosed, the one to be discussed at the upcoming BHEU talk, not any of the others discovered by the internal Intel audit).

Can an unprivileged user in ring 3 exploit any of these vulnerabilities?

Quoting directly from the IME firwmare update notes, if the attacker does not have physical access to the plaform to do a firmware flash, then they cannot do anything if the recommended flash descriptor write protections have been enabled.  If they haven't, then the attackers needs ring 0 access to the kernel, where an attacker can exploit the vulnerabilities by applying the malicious firmware through malicious driver software.  It can also be exploited remotely if the user has valid IME admin credentials, otherwise it isn't.

I came across this question whilst asking a question on Ring -3 exploits and existence of other rings


Could revealing your full name on the internet be dangerous? Apparently I can't find an answer to this on the internet, maybe because it's an obvious answer but still. Is there a reason to keep your full name disclosed on the internet?

Yes and no. What matters about online security isn't about keeping all personal information about yourself totally tight lipped, but being able to control the amount of personal information you disclose in the right context.

Online security is about being in control of how you present yourself and your online identities, and how to prevent others from being able to link the personas that you want to keep separate.

For example, on sites where you discuss your professional interests and such, you may want to use your real name, to build your personal brand that you can use with employers. On social networking sites where you associate with friends and hope to be searchable by old, lost friends, you may want to use the name you expect those people would be able to search, which is likely going to be your real name. On sites where you discuss your guilty pleasures or where you discuss sensitive political issues from viewpoints that may get you in trouble with friends and families, you may want to use a different identity which can't be tracked back to your real identity and which you should never tell anyone in your real life about. In sites where you discuss things that can get you into trouble with authorities, you may want to decide to use a throwaway identity. On sites where you do online activism, where you do need a persistent identity so people can contact you, you may want to create an anonymous identity.

Depending on how much protection you want and the sensitivity of each personas, partitioning may include using a separate email, and in some circumstances, a separate browser profile or virtual machine, and only used via proxy/tor. You may want to have multiple such identities/personas, depending on how much you want to partition your online identities and how problematic it would be for you if anyone linked those personas together.

To keep your online identities personas from being linked, you would want to learn the techniques that can be used to link up your identities. These are techniques such as Cookies, Supercookies, browser and OS fingerprinting, IP address, drag net surveillance, spyware, etc. Some of them may not be relevant to you, but you would want to learn their capabilities and how to avoid that particular techniques when they're relevant.

Or, you may decide that you want to live your life the same online and offline unashamedly, and just deal with the repercussions with a hard head. That's a valid choice as well, but be sure that when that happen that's your choice and you are in control, rather than a situation where you find yourself helplessly into.


Why is my firewall blocking on some files but not others? I'm behind a corporate firewall which restricts access to certain urls and most downloads. The download restriction is mainly on .exe(but it allows some exe files to be downloaded and I don't know why!)

The main picture here is that i can download an 'access restricted' file or exe through other means, like dropbox.

How is it possible? is it related to the way firewalls treat urls? for ex:

  site.com/install/toolname.exe

or

  dl-web.dropbox.com/get/toolname.exe?w=p4dd0df8&dl=1

or should i see much more than that? can someone shed some light on this?

A firewall is "a device or set of devices designed to permit or deny network transmissions based upon a set of rules". These rules are usually written by your network administrators, and, depending on the sophistication of the firewall, can be very simple or very clever.

Your admins have probably written a set of rules designed to allow DropBox traffic through. Perhaps an important business process (or a senior person in the business, alas!) requires Dropbox. Or they may have concluded that an executable file you have deliberately put in your dropbox is more likely to be safe than something you downloaded from the Internet.

They might have done this by writing a rule that looks at the URL (modern firewalls can do this). More likely is that they have a rule that looks at the site you are connected to. Or, they might allow secure HTTPS traffic, which Dropbox uses, but not regular HTTP traffic. Or they might only block the downloading of executables from your web browser, and allow dropbox through. Modern (third generation) firewalls can do lots of fancy things.

Also, of course, it is possible that they do not want DropBox to get though, but have made a mistake in their rule set. Network admins are human!

For a definitive answer, you'll need to ask your network admins. You might also check if you have an Acceptable Use Policy for the Internet - that may give some clues at what is filtered.


Does Windows Authentication Use Secured Connection I am writing a .NET Web API that will be used in an enterprise environment where users authentication themselves using their active directory credentials, so I am using "Windows Authentication" in IIS as authentication scheme for my API, but I am wondering does "Windows Authentication" mean by default that the connection will be secured and the data going through the wire will be encrypted? or it is just used for authentication and the encryption will be my own responsibility? and if it is, how do I secure my data while sending/receiving it if I am using "Windows Authentication"?

Windows Authentication only refers to the authentication part and does not mean that the data you transfer are protected. You still need to use HTTPS for data protection.


Are phone apps vulnerable to XSS or CSRF? (Webview, Phonegap, chrometab) Is CSRF or XSS is possible on a phone... using PhoneGap, a Webview, or specifically a "Chrome Tab" or iOS equivalent.
I believe in theory this is possible, and mitigation is needed, but looking for examples of previous exploits not done in a "browser"

A CSRF attack can only happen when cookies (or other authentication mechanisms) are provided by the client automatically. That is, where the client has access to cookies from multiple domains (such as a web browser storing cookies for each site you visit).

However, a mobile app containing a web viewer will typically only have the cookies for its own system. The cookies will not be shared with other applications using the same web viewer control. Anything loaded from the filing system will also be isolated from each other: Android and iOS  have security controls so that apps can't read other app's data. Therefore CSRF is not likely within a mobile application.

XSS could still be an issue though as anything rendered in a web page displayed by an app where JavaScript is enabled could cause JavaScript code execution if such a flaw exists, just like within a web browser.


How insecure is PowerShell Web Access? Windows Server 2012 comes with a new feature that allows you to administrate the server via a PowerShell command line in any modern browser including Smartphones.

This sounds cool and scary at the same time.

I am evaluating this option and are wondering what the risks are?

This is my current setup:

Running on Server 2012 Core
Stand-alone server no domain involved.
The site is running under SSL (required by PowerShell Web Access)
It is protected by Windows Authentication (to add another level of
security)
The url for it is not the default one but a hard to guess deep url.
There is a single user set up to use the feature.
maxSessionsAllowedPerUser is set to one. This means that even if the password of the single user was sniffed, a second session for the same user is not allowed.
After the user is done with his work, he changes his password. This is done via a script on the server. The first half of the password is a constant secret and the second half is typed by the user. This way the full password never goes over the line.
Each complex password is used only once.

To get any work done on the server the user has to be an administrator.

PoweShell Web Access is a 1.0 product, so there may be bugs in it.

Considering all this, is it advisable to use this in production on a server expose to the public internet?

As with all scenarios it depends on what you are protecting against. Generally speaking, its not wise to host administrative endpoints on public networks. In other words change the site to not be accessible on the internet.

Second, some people have problems with domain-joined servers on the internet. If its breached, then attackers have access to your domain. If you have an open Powershell connection, you've given them a great place to launch an attack. However, some people don't have a problem with it as they mitigate certain risks by limiting what that server can access internally, having a read-only domain controller be the only thing the server can talk to AD-wise, and locking down all ports but 443.

Third, some people don't like Windows auth on the internet, for the same reason as the second.

The problem with Powershell only allowing one user is that its only limited to Powershell. An attacker could potentially just find another place to login. Or they could just drop the connection of the current user before the script has a chance to run. Etc.

I'm not sure it being a v1 product is a security risk per se. There is a fair amount of effort that Microsoft goes through to make sure a new product is secure before launch. However, since it hasn't gone through the full gamut of tests by external security testers, its always a possibility there are security vulnerabilities.


What exactly is IE / Chrome checking when I view the "certification path" tab on cert connection details? When I bring up certificate details for a web page in IE or Chrome, I have the option to view the certificate hierarchy (under a tab called "Certification Path").  Here's an example for security.stackexchange.com:

I originally thought that this was a summary of the exact certificate chain provided by the server during the TLS connection + root cert on my end.  I recently observed though that the certification path section will display different things if I change my own locally stored intermediates (even though I haven't changed anything on the server side).

So my questions are:

What exactly is this checking? Where is Windows (or more specifically, the Crypto Shell Extension application) populating the information on this tab from?
How can I see exactly what the browser got in terms of the actual certificate chain (assuming that the server in question is not publicly accessible)

What exactly is this checking? Where is Windows (or more specifically, the Crypto Shell Extension application) populating the information on this tab from?

It is showing the trust path it constructed based on the certificates sent in the SSL handshake (ignoring any root certificates sent by the server), the cached intermediate certificates from other connections, the built-in root certificates and any other certificates it has in the store. Some browsers also download missing certificates and these will be displayed too.

  How can I see exactly what the browser got in terms of the actual certificate chain (assuming that the server in question is not publicly accessible)

You will not get this information from the browser. You might use tools like openssl to display the certificates the tool gets:

openssl s_client -showcerts -servername host -connect host:port

These are in most cases the same certificates the browser sees, but a server might actually decide to return different certificates based on parameters of the SSL handshake initiated by the client. This is specifically relevant for the SNI extension so you must include the -servername option with s_client.

But to get a definite knowledge of what the browser sees you need to do a packet capture using tools like tcpdump or wireshark. When viewing the capture with wireshark you then can see the certificates sent by the server. To make sure that you don't get a session resumption where you don't see any certificates make sure you restart the browser before visiting the relevant site.


Employer Self Signed Root Certificate I don't have knowledge into programming/cybersecurity so I stumbled upon this site and figured I'd ask a quick question. I worked for about 3 years at company and left as of last week. I don't know how I remembered this, but I recall installing a "root certificate" on my phone and laptop. Long story short, I was able to find it (mac laptop) and it says "self-signed root certificate". I may be wrong, but I believe this was installed when either connecting to their internet or going onto the company email server.

I don't know if i need to put the details of the certificate, but long story short. Does this mean that all network traffic (when not connected to the company wifi) was being monitored? I went ahead and deleted the certificate.

I apologize if this isn't the place to post this question, or if I'm just completely wrong in my thinking. Thanks in advance

Does this mean that all network traffic (when not connected to the company wifi) was being monitored?

The traffic was likely monitored while you were in the company since your traffic there went over the corporate firewall. While you are outside the company your traffic usually goes not over this corporate firewall (unless you use a VPN into the company) so they could not monitor you.

In theory the company could use this certificate if they manage to control your traffic. This could be for example the case if you use the companies DNS server or if they explicitly attack your network. But, while possible, this is unlikely as long as the company you work for has proper ethics and has no real reason to monitor you after you've left the company.

In any case it is good that you've deleted the companies root certificate. And if you did not get any errors while visiting HTTPS site after you've deleted the certificate it is very likely that they don't monitor you now and probably did not monitor you before after you've left the company.


How many possible randomly generated salts could be generated using PHP's password_hash() function? I have two questions here:

1) How many possible randomly generated salts could be generated using PHP's password_hash() function?

2) According to php.net it states that the return value is a contains "the algorithm used, the cost and salt are returned as part of the hash" and I assume the hash itself. So from my understanding in a returned string of $2y$10$x27FUiXA/hFKjD7NDxyD6e63ac4gmCkTqXRpmy1Rk.MxXAqRd8yO6 the 2y indicates the algorithm, the 10 indicates the cost, but which characters indicate the salt and which characters indicate the hash?

1) The salt for password_hash() is a 128 bit salt which is the first 22 base64 characters after the cost factor. In your example, the salt would be x27FUiXA/hFKjD7NDxyD6e. Because it is 128 bit, you can calculate the number of potential salts as 2^128 which is 3.4028237e+38. So, in short, a lot.

2) Well this didn't seem like a question so i'll try to answer the "which characters indicate the hash" part. The hash are the remaining 31 characters after the salt. In your case 63ac4gmCkTqXRpmy1Rk.MxXAqRd8yO6.

(also, your understanding is correct. 2y is the algorithm, and 10 is the cost.)

It is important to note that password_hash() can change its implementation to use a different algorithm if you update PHP to a newer version that changes it.

  PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP.

If you use PASSWORD_BCRYPT it will always use bcrypt.


If someone steals my unencrypted, password protected laptop, would they be able to get into my Google account? I have a laptop with Ubuntu 20.04 operating system. I am logged into my Chrome browser using my Google account. This means, every time I open my browser, I am already logged into all the Google services (Gmail + Chrome browser with all passwords + Photos + ...).

Let's say that someone would steal the laptop and would like to get into my Google account. What the attacker can do is boot his own Ubuntu from a pen drive and see the contents of my home directory. In this directory are, presumably, the login data (.config/ ...) that allow the Chrome browser to authenticate me. The attacker can then just copy this data to his own computer and impersonate me. Or can he?

There are two possible mechanisms that could prevent this:

Two factor authentication.

Each time I reinstall my system, I am asked for my password and security code. This is true even if my home directory has been left intact during the system re-install. It seems that Google somehow fingerprints the operating system to protect against this type of attack.

Encryption of the Google login data

I am not sure Ubuntu has a mechanism to do this, but if in fact some data was encrypted by default until you log in to the OS, this would save the day.

Are there some mechanisms that would protect the Google account in case of access to an unencrypted harddrive?

If someone steals my unencrypted, password protected laptop, would they be able to get into my Google account?

Yes.

Each time I reinstall my system, I am asked for my password and security code. This is true even if my home directory has been left intact during the system re-install. It seems that Google somehow fingerprints the operating system to protect against this type of attack.

They indeed fingerprint your OS and look for discrepancies, including source IP address/location, user agent, etc. I'm not 100% up to date about how they deal with these discrepancies.
As to resuming established sessions, a fresh build will have an empty cache and no cookies, so you'd naturally have to login. If you import your home directory you should be able to resume an established session. Specifically on gmail, on "trusted computers" the session cookie will last for at least 30 days before they require 2fa or a full re-login. You have some control over this, but ultimately it's the implementation of the application that dictates how the session management layer works.

I am not sure Ubuntu has a mechanism to do this, but if in fact some data was encrypted by default until you log in to the OS, this would save the day.
Are there some mechanisms that would protect the Google account in case of access to an unencrypted harddrive?

Full disk encryption is the definitive solution for private computers. On shared workstations, if you must use them, make absolutely sure you always logout from your session before leaving.
There are ways to encrypt home directories, but none that I would call simple or practical to implement. This is proposed to change by systemd-homed but it may take a few years until this trickles down into a default in desktop distros.
Browsers apply a level of encryption to their caches, but since you can usually use them without providing credentials, these are relatively weak protections.


Xmas Scan Versus FIN Scan While studying Nmap, I came across different port scans. Out of these XMAS and FIN scan caught my interest. Though XMAS scan sends FIN, URG and RST flags, the response is the same as that of a FIN scan, which only sends a FIN packet.

How do I decide when to use XMAS or FIN scans when both have the same response and same limitations?

NULL, FIN, and Xmas scans all send packets without SYN, ACK, or RST flags. They should all get the same responses, according to the RFC, but different implementations may treat them differently. If you want to use one, it's best to find one open and one closed port by some other means (such as open source intelligence gathering) and then test each of the scan types against those ports only. Whichever one(s) give the correct output can be used to further scan the system.


How to secure a truecrypt container allowing access with multiple SSH public keys? I would like to create a TrueCrypt container which can be accessed by multiple people. The container itself can be stored anywhere, e.g. in a shared folder in Dropbox or Google Drive, ...

I would like to add each person's SSH public key to the container encryption mechanism, so that they can use their SSH private key and passphrase to access the container's content.

Is this possible? How?

The data itself can only be encrypted by a single key without having to encrypt the information multiple times (which also wouldn't allow for information to be shared between users).  What you would want to do is have a master key which is then protected multiple times, once for each of the users.  Each user could then access the key to access the container by using their own key.

I've not worked with TrueCrypt myself, so I'm not sure if it is viable to do this in an automated way or not.  It's worth noting that this would also likely not provide a guarantee that any one user not masquerade as another.  It would be far more complicated to pull something like this off as I would think it would require some kind of a versioning system where each revision was stored, signed by the user and then applied, but then changes would have to be replayed (either to get the current state of the data, or played in reverse to validate the revision history hasn't been tampered with).


If I am not logged into my company's WIFI, can they view my information? Or am I transmitting? I was at work using my phone. We have an open WIFI, but I did not use it to go online. I was wondering, can my information be viewed or was I transmitting data even though my phone said I was not connected to their WIFI?

If you are connected to a mobile network instead of your companies wifi they shouldn't be able to view traffic coming from your phone. However, if the phone is a work phone (provided by them) then the statement above may not apply; they could have installed applications designed to monitor employees.


Is there a default assets grouping in order to perform Information Security Risk Assessment? I am working on the implementation of an ISMS and aiming to get 27001 certification. While i was conducting the Risk Assessment, I found it difficult to match all those assets/asset components with all the threats/threat events without making exhaustive and unmanageable lists.

I found many threat lists with their supporting threat events over the internet, but i can not find something similar for assets and asset groups.

Is there a methodology, guideline, etc. that proposes a specific group of assets (e.g. People, 3rd Parties, Hardware, Information, etc.)?

There is no specific methodology you can do it as per your organization structure,asset distribution, asset usage etc.
However, as per ISO 27002 under clause 8.1.1 mentions that the asset inventory should be made along with ownership and classification (see 8.2) information.
When you look at the 8.2, it mentions that assets can be classified in terms of its legal requirement, its value in organization or process, criticality of asset and sensitivity of asset in terms of information it holds is secured from to unauthorized disclosure or modification.

Based on above classification then it would be easy for you to identify the risk for the assets as it has already been classified in terms of criticality and sensitivity.

Hope above explanation helps.


IPv6 and NAT firewall effect It seems that people still argue on whether to use NAT with IPv6 for its side-role as a firewall hiding inner network from the outside (providing user anonymity and security as well). I am wondering though if we could not use an actual firewall for this purpose to secure an inner IPv6 host against outsiders (this however won't protect the user anonymity) ?

NAT is mostly a non-issue with IPv6. As you say using a firewall (which should even be used with NAT, because NAT is not a proper security measure by itself) is the proper solution.

Hiding the client's IPv6 address will only cause problems for protocols, traceability and security's Knowing the client's actual address makes writing firewall rules so much easier, and therefore prevents mistakes.

As far as the technical community is concerned the consensus is to avoid NAT with IPv6.

PS: NAT64 is used for IPv6-only networks to connect to the IPv4 world, but the IPv4 world is already full of NAT so it's considered an acceptable solution.


Indirectly relaying intranet server to outside world I have an internal network of IP network cameras. The feeds from these cameras are ingested by a single server and presented from a unified web interface both internally and to the outside world (both after password screening).

There are two layers of protection - one fairly simple one at the barrier to the WAN that designates a second router as a (still limited) DMZ. The first one has some basic controls in place on type of traffic, detecting port scans and DoS attempts. While a range of ports are permitted through, key unwelcome ones are prohibited and the ports that the cameras are configured to use for communication are explicitly excluded. The second router (that handles internal traffic and their connection to the outside world) port maps to specific internal servers with unintended traffic otherwise blocked there. The network cameras may be viewed and controlled from the web interface within reason - there are a number of preset locations and scan settings for each. To communicate directly with any of the cameras would require hacking each of the routers themselves - and they are configured to only permit logins from the internal network.

The cameras contain their own http host and services - and the server that I access from outside connects to those cameras and relays images, jpeg streams, etc. to the outside world. I want to be able to optionally provide relay service to those cameras' admin interfaces without directly providing routing to those cameras from the outside world (simply because I can control what software is on the relay host but have relatively little control over the camera firmware). There are a variety of administrative features of the cameras (control over infrared, changing preset angles, etc) that I would rather avoid having to write alternate interfaces to and would like to be able to provide their interfaces through a relay that I could monitor and filter should exploits for the cameras themselves become known. Mostly, I'm concerned that since the cameras themselves are fairly sophisticated web hosts, that if directly revealed to the outside they could roll out the welcome mat to intruding on the internal network. I've done a lot to limit my exposure (and thus let me concentrate my security efforts). Opaque third-party hardware shouldn't be my weak spot.

An http relay wouldn't be completely onerous to write - I've done a fair amount of port-level coding in the past - but mature, existing solutions would be nice.

So the question is: is there an approach to implementing an existing http relay that will meet my requirements?

(Note that I'm currently using VPN to get into the network from outside when I need to tweak something - but that's not the user experience I'm looking for)

Proxying as you propose doing gives you the ability to add additional authentication and encryption, but nothing else.

IP cameras have terrible interfaces and terrible code. If you simply proxy the requests you will be proxying every possible exploit in the camera. If authenticated user sessions are considered a potential attack vector in your risk assessment, you shouldn't simply proxy, you need at the very least to validate every request is expected.

If authenticated user sessions are not considered an attack vector in your risk assessment, then that's a problem you should fix first.


Best tool to BruteForcing RDP I have tried many tools and to do not seem to be successful with locking out an account I am testing on my network with an RDP domain. I used crowbar, ncrack and THC hydra but they don't seem to be working accurately. Can someone point me in the right direction on how to approach this for testing?

If you are having issues with hydra and ncrack, I might suggest trying Patator, but really you want to troubleshoot what is going on.

For a thorough check that also involves an additional layer of testing, try — https://github.com/SySS-Research/Seth


What are the places one should look for CSRF flaw? While finding vulnerabilities in a web app what are the potential areas where one should look for CSRF flaw?

Cross site request forgery (CSRF) is performing a "forged" request from the attacker's site to another site where the victim is logged in. If that site is vulnerable, any action that the user could normally perform on the site can now be performed by the attacker.

An interesting action to perform through CSRF is changing the password or email address, as this results in account takeover. For passwords this is often impossible since you have to fill in the old password, but for email addresses this is sometimes forgotten.

Other interesting actions depend very much on what the purpose is of the attacked site. Here on sec.se, I would trigger upvotes on all my questions and answers through CSRF.

Requests that perform some action are supposed to have CSRF protection and are interesting to test. Most of the time these are POST requests, but not always. Some sites do have CSRF protection on all POST requests, but not on GET requests. In that case it is interesting to search for a GET request that performs some action.

One request that can often be forged is to log out the user. On most sites, simply visiting /logout or something like that will log out the user. This is technically CSRF, although with a rather mundane impact.

CSRF protection is typically done by sending a random token along with any request. The attacker wouldn't have this token and thus can't forge a valid request.

Sometimes the site verifies the Referer or Origin headers to verify that the request came from the site itself. This can be secure, but is a bit harder to get correct. Sometimes the site checks whether "https://www.example.com/" is contained in the Referer, in which case it can be attacked by using "https://www.attacker.com/?https://www.example.com/" as the attacking page. Sometimes the check isn't done if the Referer header is missing, which the attacker can trigger through a referrer policy.

Finally, Same-Site cookies provide adequate protection against CSRF, but only for browsers that support them.