Can a 3rd-party iOS 12 app use any of the cameras without the user being aware? Now with iOS devices having Face ID, there are potentially 3 cameras. But there is only 1 access permission for "Camera" in the Privacy settings.

Well-Behaved apps use the camera in conjunction with an on-screen viewfinder of sorts to let you know what the app is going to capture.

Comments on this old question imply that apps can capture images at any time. Clearly now that at least requires access permission.

Assuming a non-jailbroken device with "Camera" access granted to the app, can that app take stills or video with the front camera, back camera, and / or the TrueDepth (Face ID) camera, without making the user aware?

For example, can an app surreptitiously take a selfie of you while you are using the app to take a picture with the back camera? Or can an app use any camera without showing you any kind of viewfinder of what the app can "see", or without any indicator at all that it is capturing imagery and potentially transmitting it to the app maker or an app-embedded 3rd-party?

You can put a sticker over the front camera of any iOS device, including those with TrueDepth, but you can't cover the TrueDepth camera if you want to use Face ID for authentication. Given the potential sensitivity of the TrueDepth data, this is concerning.

The answer is yes they can (at least for the front and back facing cameras), but that goes against Apple’s App Store review guidelines.

https://developer.apple.com/app-store/review/guidelines/

  2.5.14 Apps must request explicit user consent and provide a clear visual indication when recording, logging, or otherwise making a record of user activity. This includes any use of the device camera, microphone, or other user inputs.

I’m not sure exactly what sensor data is returned by the Face ID API, but I assume that data can also be collected without notifying the user (assuming it has permission to access Face ID).

So the answer is yes they can, as long as they don’t get caught by Apple.


Tunneling over a HTTP subfolder? I have a firewall, which only forwards HTTP requests, and only if the request is pointing to something in a /admin/ folder, so it only lets through requests like this:

http://www.anysite.com/admin/anyfile.file

I can bypass this and view any site with a PHP Proxy (web proxy, using this: php-proxy.com) in a /admin folder on a webserver, but it only works through the web browser.

Is there any way to create any kind of tunnel (VPN, SOCKS proxy etc.) that can use this folder to route any traffic trough?

TL;DR That proxy does not allow for tunneling.  And you have a firewall that parses the HTTP requests, likely to disallow HTTP tunneling altogether.  You're pretty much limited to GET and POST.

Since you can resolve DNS, and IPsec VPN on port 53 may be a good alternative.

php proxy is not a standard general proxy.  In other words it does not follow (general) proxy standards (HTTP CONNECT or SOCKS), it simply is an HTTP proxy for GET and POST requests.  It is not a full HTTP proxy implementing HTTP CONNECT which would allow for tunneling connections and bypassing a firewall.

In the code php proxy uses CURL, more exactly curl_exec, as follows:

$result = @curl_exec($ch);

// there must have been an error if at this point
if(!$result){
    $error = sprintf('(%d) %s', curl_errno($ch), curl_error($ch));
    throw new \Exception($error);
}
// we have output waiting in the buffer?
$this->response->setContent($this->output_buffer);

// saves memory I would assume?
$this->output_buffer = null;

Even if you send an HTTP CONNECT the proxy will return to you the response to that and close the connection, which is not how HTTP CONNECT works.

That is not to say that CURL cannot work with HTTP CONNECT, it can, but not through PHP curl_exec.

All that said.  You have a stateful firewall that analyses HTTP headers (since it only allows for /admin/ only).  I highly doubt that the firewall will allow you to send an HTTP CONNECT in the first place.  In other words, if the firewall rejects this (note the typo):

GET /typo-in-amdin/somehting HTTP/1.1

Then I do not believe it will allow:

CONNECT /admin/somewhere HTTP/1.1

Since it would fail on the same regex match.  And since your firewall only allows HTTP through (and parses it) you cannot use other protocols, e.g. VPN on posrt 80.

Extra (more optimistic) note

One thing that strikes me is that you can resolve DNS.  Therefore the firewall must allow UDP packets on port 53.

And, unless you are using an internal DNS server (and so the DNS resolution is not passing through the firewall), you can get around the HTTP header limitation by running a VPN in udp mode (IPsec) and "connect" to port 53.  That will tunnel your traffic, and will look to the firewall as DNS requests and responses.


If I obtained a username and the salted password pairs from a server, can I login? I am studying Salted Challenge Response Authentication Mechanism (SCRAM).

According to the description at https://tools.ietf.org/html/rfc5802#page-8 it seems that the Client does not have to know the password in plain text; knowing the SaltedPassword is enough to compute the ClientProof.

That would mean that if I manage to obtain the salted passwords from a database, I could log in without having to brute force the passwords.

Is my understanding of SCRAM correct in this respect?

Disclaimer: I'm no expert in cryptography so this answer come from my limited understanding of the protocol.

Let's look at the protocol

SaltedPassword  := Hi(Normalize(password), salt, i)
ClientKey       := HMAC(SaltedPassword, "Client Key")
StoredKey       := H(ClientKey)
AuthMessage     := client-first-message-bare + "," +
                    server-first-message + "," +
                    client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof     := ClientKey XOR ClientSignature
ServerKey       := HMAC(SaltedPassword, "Server Key")
ServerSignature := HMAC(ServerKey, AuthMessage)

Who know what at the start?

The server knows : salt, i, StoredKey, ServerKey
The client knows : password
Both parties know the AuthMessage as part of the exchange

The answer

You are right that only the SaltedPassword is required to compute everything but the problem is that no one stores that SaltedPassword. Also, if you want to simply impersonnate the client, you only need the ClientKey to fool the server.

The idea behind SCRAM --> A failure?

  The secure authentication mechanism most widely deployed and used by
  Internet application protocols is the transmission of clear-text
  passwords over a channel protected by Transport Layer Security (TLS).
  There are some significant security concerns with that mechanism,
  which could be addressed by the use of a challenge response
  authentication mechanism protected by TLS.

Still, it doesn't seem to explain how it will protect the password from the server. You have to understand that even if you use some kind of fancy challenge response mechanism to "never" send the password over the wire, that when you enter the password on the browser page, that is served by the server, the script in the page could decide to record your password even if it tells you that it doesn't.

The main advantage, that I see, of a challenge-response mechanism for the users is that they would be able to reuse the same password everywhere. But, since the user really cannot trust the page where it enters his password, he cannot reuse his password.

Then, the next big advantage that I could think of is that in a challenge-response mechanism the password usually isn't stored on the server. So, even if an attacker stole a copy of the server, he cannot try to de-hash the password. Again, it's a big fail since the server has a copy of the StoredPassword, the salt and the iteration count. He has all he needs to try to crack your password via dictionary or bruteforce attack.

At some point, I have to wonder, why not just give the password to the server? The only protection that it adds is that if TLS is broken (but the attacker can only listen), the attacker still has to brute-force your password in order to gain access.


Is it safe to leave MySQL root user without a password if it uses auth_socket? Since MySQL 5.7, the root user is configured to use the auth_socket authentication plugin instead of a password.

Is it safe to leave the root user that way (without a password)?

MySQL socket authentication is a bit different from conventional authentication. Instead of requiring you to type in a password, it simply checks who you are on the system. From the MySQL developer docs:

  As of MySQL 5.5.10, a server-side auth_socket authentication plugin is
  available that authenticates clients that connect from the local host
  through the Unix socket file. The plugin uses the SO_PEERCRED socket
  option to obtain information about the user running the client
  program.

  ...

  The socket plugin checks whether the socket user name
  (the operating system user name) matches the MySQL user name specified
  by the client program to the server, and permits the connection only
  if the names match.

  Suppose that a MySQL account is created for an operating system user
  named valerie who is to be authenticated by the auth_socket plugin for
  connections from the local host through the socket file:

CREATE USER 'valerie'@'localhost' IDENTIFIED WITH auth_socket;

  If a user on the
  local host with a login name of stefanie invokes mysql with the option
  --user=valerie to connect through the socket file, the server uses auth_socket to authenticate the client. The plugin determines that the
  --user option value (valerie) differs from the client user's name (stephanie) and refuses the connection. If a user named valerie tries
  the same thing, the plugin finds that the user name and the MySQL user
  name are both valerie and permits the connection. However, the plugin
  refuses the connection even for valerie if the connection is made
  using a different protocol, such as TCP/IP.

To summarize, this protocol assumes that a user who is already logged in to the system should be allowed to log in to the database as that user (assuming that user exists in the database). So, it relies on you having secured the server such that users who are accessing the database should already be trusted.

It also doesn't affect your remote attack surface, as the socket authentication can only be used locally.

TL;DR: as usual, your database's root account will be only as secure as the root account on the system.


Are there security risks in exposing a certificate? If an attacker would have access to a certificate, could he build an
attack out of that?

or rephrasing it:

How could an attacker profit from a device certificate, that he gets his hands on?

For example: A certificate that is used for a device (IoT-Device) gets public, which is in my mind part of the idea of using it, could an attacker profit from that?
For example clone it for a different device.
Deleting or making the certificate invalid is not an attack in scope in this scenario.

Assumption is:

the private-key is still safe
the CA oder ICA that signed the certificate is valid and secure
Data in the certificate is not confidential, but there is an ID for the device
the attacker is in possession of the certificate file

And following out of that question, if the answer is no, there is no threat.

I could store the certificate on the device, without thinking to
much about security (except deletion and changes that lead to
invalid behavior)?

In a PKI (public key infrastructure) scenario, there is no harm in exposing the certificate - in fact it is necessary to expose the certificate in a PKI scenario.  This is because the certificate contains the public keys of the server that you are creating the secure connection with.  Moreover, the certificate contains information about the party that operates this server, so that you can be sure that they 'are who they say they are' when you connect to the server.  This information is verified by a trusted third party certificate authority (CA), and the certificate is signed by the CA.

As an example, if you go to any secure web site (such as security.stackexchange.com or www.bankofamerica.com), you can easily view the site's certificate in your web browser by clicking on the padlock to the left of your address bar, then following these steps.

Now, in addition to the certificate, the server must have the private key that corresponds to the public key in the certificate.  The private key must not be exposed.  If it is, then anyone with the private key can impersonate the server or eavesdrop on a connection with the server.

However, the certificate is of no use to an attacker, if the attacker does not have the private key that corresponds to the public key in the certificate.  See Could a stolen certificate show as trusted? for more info.


When MBR pirates grin as an indication of absolute pleasure! Someone, have no idea who, really worked my computer, and placed some rootkit, all-knowing, all-smashing malware something and I simply cannot keep Windows OS clean in a multiboot configuration with Ubuntu even after removing MBR, deleted all partitions and partition table, and reinstalled Ubuntu with Grub only, and no MBR.

The symptoms are, for the Windows part, that group policy rules are changed soon after establishing the internet connection and reboot computer. Local System is replaced by either SYSTEM and/or SERVICE and I can no longer find Local System when trying to restore the defaults, and it goes on like this with other locations/services, and I also find a lot of unknown executables inside the windows root folder, and system32 also with only one or two reboots after a fresh install of windows. When trying to install antivirus software I experience some delays, and only the firewall is able to block part of the unusual network activity.

Several attempts to reinstall Windows after installing Ubuntu were pathetic, I always seemed to get stuck to some point where the ugly malware rootkit something showed up and started doing its business as usual. I feel like being haunted and have no idea what to do or whether this nasty pirate is able to track me, and somehow infect my system again.

On top of all these, I recently noticed BIOS not being able to set time precisely, it is always a few hours backward. Is there anything I can do to erase this malware or to prevent further attacks? I've tried them all, antimalware, antivirus, antipirate software, and with very few results. I was thinking to delete all data on hard disk again, format and delete new MBR left from previous windows installs, and start it over using some Ubuntu Live Cd. Or maybe change my hard disk or what?

This is a new entry in my post as requested by user @mgjk who asked me to describe my problem with more details

As requested by @mgjk in his reply, I have to describe my problem using more details, and to be specific I think it is mostly about a virus described on this page, a virus/malware known as Trojan:Win32/Spyeye which may be, among others, related somehow to Systray .exe stub file usually located in /windows/system32. They say most AV software won't detect it, and I did try many solutions to eliminate it with no results.

I usually run WinXP, it is compatible with my ancient Dell machine. As for the specific symptoms, I sometimes could not have access to right-click menu commands in Windows, they were present but did not activate, or the taskbar did not show any of the open windows/apps, instead they were present on top of taskbar as if they were shrinked, and when it got really ugly I could not have access to most usual commands like stopping a process in Task Manager, using Regedit or editing system rules and policy using Gpedit.msc tool.

As already told in a previous comment, my ISP told me to install Kaspersky AV, latest release, and after first reboot I got yet another thingy on my Windows, which is known as das boot virus or something like that. Great idea, what can I tell, use Kaspersky to get rid of Spyeye. I should have known better.

A totally different angle on this would be to step back and consider your analysis.

You have a hypothesis that your machine is infected with malware.
You are collecting evidence through your attempt to build the machine into a dual boot configuration.

To determine if it is true that you have malware, you'll need to come up with a test of this hypothesis.  The test might be to demonstrate well documented behaviour which cannot be explained by experts on the OS, or well documented behaviour which cannot be reproduced.  I personally document this stuff with pen, paper and a camera.

You performed some installations and have observed unusual results, but your observations aren't well documented (at least here).

"Windows OS" - What version of Windows?
"A lot of unknown executables" - Do you have a list?
"Local System is replaced by either SYSTEM and/or SERVICE and I can no longer find Local System when trying to restore the defaults"  - where? how did you check?
"When trying to install antivirus software I experience some delays, and only the firewall is able to block part of the unusual network activity" - what unusual traffic did you detect?  How long are the delays?  when do they occur?
"I always seemed to get stuck to some point where the ugly malware rootkit something showed up and started doing its business as usual" - When do you get stuck?  What prevents you from continuing?

Having precise information about any one of these unusual behaviours could help.  There may be a non-malware explanation for the problems, or you may document behaviour unique to a very specific bit of malware.

Regarding your clock:  Setting the clock back a few hours in the BIOS sounds like normal multiboot behaviour.  Some OSes store the time zone as UTC, some store it as local time.  This is usually only noticable in a dual boot configuration  See further: https://superuser.com/questions/185773/does-windows-7-support-utc-as-bios-time

You can test the theory by booting to one os, checking the time, shutting down, checking the time in the BIOS, then repeating for the other OS.   If you can resolve the issue or influence the hours by changing the way the OS stores the time or even the time zone in the OS, then you have pretty good evidence that you've identified the cause.


When Securing a Websocket connection, does the url have to be hard coded? I have been looking at tips to securing Websocket Connections and found this article https://portswigger.net/web-security/websockets which states that one should "Hard code the URL of the WebSockets endpoint, and certainly don't incorporate user-controllable data into this URL."
Currently I have been taking a part of the URL using window.location.pathname (which I'm not sure if this can be manipulated) in order to grab a name (i.e., music, movies, etc) that I then compare with entries in my DB to make sure they exist in order to continue with the connection.  I have also seen similar examples doing this for reasons such as a chat room in order to keep chats for a single topic to the same ServerEndpoint.  I found this page from Oracle that talks about creating this on a Java Server, to which they call it "URI Templating"   https://docs.oracle.com/javaee/7/tutorial/websocket008.htm
The thing I want to know is how is one supposed to hard-code the URL if we have dynamically created data that affects the URL (again Music, Movies, etc topics that can be added).  The only way I can think of now is creating a script on the html page I'm serving up that has the Websocket info hard coded when serving the page from the server, but since I'm looking to work with a WebWorker, I'm not sure if there will be some issues with that.
As a NOTE:  Invalid URLs wont load the Websocket JS file/code so if I it's not a valid room (i.e., Music), there is no connection.  Malicious URLs are the only way I can see something happening with this setup, and I can see why hard-coded is mentioned as the secure method; however if I'm stopping invalid URLS from loading the correct page, as well as checking to make sure the part I'm grabbing (i.e., Music), actually exists in the DB, would this be secure?
So, my question is, is what I'm currently doing not secure, by referencing the window.location.pathname and doing the checks stated above? If it is not secure, and needs to be hard-coded, how should I go about creating a "hard-coded" Websocket URL when I have variable data that could be used as the endpoint URL?  I'm also curious if a malicious URL would affect users on a case-by-case basis, or is there something deeper going on with being able to create any endpoint URL?
Thank you.

Assuming you control all the server-side code on a given origin (that is, there's nothing at the same scheme://host:port combo that is controlled by somebody else), then that's the only part you need to hard-code. In other words, you can hard-code wss://my.domain.com/ (with the port implicit) and as long as you (or a trusted third party) control all the content on that domain, it's fine to dynamically generate the rest of the path to the WS endpoint.
Regarding spoofing the window.location, this is sort of possible - code running on the page can set any path (without changing the origin, or causing an actual navigation) by calling pushState - but that's only a risk if either the site allows untrusted content to be passed to pushState, or if the site can be loaded using a URL with a "weird" path that might look like it's for one page but actually be for another. Assuming you're successfully "stopping invalid URLs from loading the correct page", it's probably not a big concern.
With that said, it's pretty easy to avoid performing concatenation of the WS URI on the client. One option is just to have a single WS endpoint (or a small, known set of them) and send data like what type of media the user is accessing in a message body. Another is to have a fixed list of known WS endpoints that are hardcoded in the script, and select one dynamically based on the current page/URL. Finally, you can ask the server to give you the current endpoint or list of endpoints (generating it dynamically, perhaps in response to some info sent with the request, rather than hard-coding) using AJAX, and either just use the returned one or pick one from the returned list as appropriate.


kadmin problem: "Client not found in Kerberos database while initializing kadmin interface" I'm having problems setting up Single Sign On on my Mac (Snow Leopard). My program was giving the error
accept_sec_context: Unspecified GSS failure. Minor code may provide more information: \
Key table entry not found (000d0000:96c73ab5)

When using the Mac built in library (/usr/lib/libgssapi_krb.dylib). It works fine with Likewise.
I'd set up an identity for myself in Ticket Viewer, and issued a ticket. I'm now trying to go through the set up process manually from the terminal. So far so good, up until I get to the Install the Slave KDCs step, where I can't start kadmin. I get the following output:
$ kadmin
Authenticating as principal me/admin@CORP.ORG with password.
kadmin: Client not found in Kerberos database while initializing kadmin interface

I added myself to the keytab using ktadd in kadmin.local, but this hasn't worked. I'm stumped as to how to progress from here.
Update
Running kadmin -p me prompts me for my password, but still rejects me with error:
kadmin: Database error! Required KADM5 principal missing while initializing kadmin interface

"Client not found in database" means the principal you used, me/admin, does not exist.

"Required KADM5 principal missing" means that your Kerberos database is missing principals for kadmin/fqdn.of.the.kdc@CORP.ORG as well as the legacy fallback kadmin/admin@CORP.ORG. Add them through kadmin.local.

"Missing keytab entry" usually refers to the service principal on the server's keytab (e.g. host/fqdn.of.my.server).


Can a driver(malware) hide it self from device manager? For security reasons, I have this question in mind. I am not a security professional, so I want to ask:
Let's suppose my computer's firmware is hacked. If I disable the wifi driver on windows, can a kind of virus (hidden driver software does not appear in device manager), or the firmware (if infected) use the wireless device to connect to the internet without overriding the old driver? And can it hide itself from the device manager?

Can drivers?
Yes. Most Windows (and Linux and Mac) drivers run in kernel mode and have full access to the operating system, including the parts that store the list of drivers. They can erase themselves from that list (and similar lists) and still continue to operate. It would have to be done on purpose, maliciously.
Plus, Device Manager shows devices, not drivers.
Plus, the driver is the one that knows whether the device is enabled! It could pretend to Windows that the device is disabled, while actually it's enabled and transmitting spy data.
"forest" mentioned in a comment that some hardware can be turned off. Of course even a driver can't use the hardware if it's turned off. I strongly suspect the driver can turn it back on without Windows noticing.

Can firmware?
Yes. Except if the device with the firmware is turned off (as pointed out by "forest"). If your wi-fi card is turned off (no power) then it doesn't matter what firmware's on it. If it's turned on though, it can do evil stuff. If it's different firmware that's infected (like your BIOS/UEFI) then it can turn on the wi-fi card and then do evil wi-fi things.
Firmware doing evil wi-fi things and drivers doing normal wi-fi things would be likely to clash with each other and cause the wi-fi card to stop working properly, so it's not likely, but it's possible.


How is HTTPS Everywhere leaking my Twitter session from an incognito window? I manage a couple of twitter accounts for businesses/websites that are separate from my personal account. For simplicity, I prefer to log in from an incognito window so that I don't need to log out of my primary (personal) twitter account.

I was shocked when I recently logged into one of the secondary accounts in an incognito window, closed the window, and later was logged into that secondary account when visiting twitter in the non-incognito main window.

I did some testing, and found that the auto-login occurs regardless of whether I'm currently signed in to twitter or not in the main browser session, any time I sign in via the incognito window. If I leave the incognito window open and log into a different account, the primary browser session also switches to that twitter account.

After some additional poking around, I decided to disable any extensions I had enabled in incognito mode, to determine if that was related. The problem disappeared with all extensions disabled. The only 2 extensions I had given permission to operate in incognito mode were Adblock and HTTPS Everywhere. I enabled each of them individually, and the problem only occurs when HTTPS Everywhere is enabled. I further established that the problem only appears to happen on Twitter. Logging into a different Facebook, Gmail, or Reddit account in incognito mode (with HTTPS Everywhere enabled) did not affect the login status in the primary browser session.

Obviously, this is a security concern, especially for a privacy-oriented extension to be leaking session data. Specifically, I am wondering:

How does HTTPS Everywhere help Twitter escape the incognito mode "sandbox"?
Why does this happen with Twitter but no other sites?
In what ways could a malicious website exploit this bug to steal or alter user credentials?

Note: this does not happen in Firefox using Private Browsing Mode with HTTPS Everywhere enabled.

I'm the maintainer of HTTPS Everywhere and just merged a pull request fixing this issue. It should be in the next release (out in 1-2 weeks). For future reference, submitting these to Github means they'll get fixed sooner :). (https://github.com/efforg/https-everywhere)


Security implication if android app can be installed on emulator I am working on ensuring security of my company's product. We have a mobile version of the product. This question is for the Android version

Background -
Our product is a SaaS-based product and the app is meant to be used by different salespeople of tenant organisation. We have implemented different layers of control for ensuring secure (or more like safe) environment for our app -

We check for root detection - (OS level check)
Implemented SSL pinning - (Transport layer level check)
Storing secrets in Android key chain
Minimal local data storage. Encrypt local data (that needs to be stored)

and the list goes on. In short, right from the device to the communication layer to the server layer we are in the process of covering every corner.

The problem is we got one issue reported by one of the security researchers that says that as our app can be downloaded from the Android play store thus it can run on an emulator, and on an emulator, it is possible to bypass root detection. So it adds a huge threat and should be fixed immediately.

I searched, but I cannot find security implication that could be possible if app can be installed on the emulator. Also I checked if I might have to fix it, what could be the possible solution. There are checks like looking if the running environment is an SDK, check if features like camera or sensors are working, but all those checks can be bypassed in emulator also.

It is kind of critical for me because if I accept this issue our client will see it in report and insist on getting it fix. I'm coming up blank for the implication that I would have to explain to Management and developers (if I accept) and fix (that might be required later)

Update -

I want to clarify one thing that we never advocate root detection or any other client side security controls as a plus point of our app because we believe all client side protection can be bypassed at one point or the other
We keep on trying to build more secure architecture at the server level. But since client side also forms the part of eco-system so we cannot leave it unguarded.
We even try to implement controls at the communication layer (other than TLS) to ensure just by tapping in you cannot get everything

Whole idea is if we cannot control certain things we can at least make it difficult for malicious parties. Our primary focus is to secure our users data and controls are in place and in progress.

Also update from Pentester - After discussion with him, he said that he didn't understand the application security requirement. As per him all app should have root detection. We explained him that those things means secondary to us but if any client specific data is lying in plain sight or can be compromised because of misconfiguration in app or any vulnerability in app (like hard coded secrets) then that it is primary.

Based on input provided you guys I was able to make this distinction clear and help in closing down the issue. Earlier it was all noise because of this issue. Thanks to all

It is unclear what kind of security requirements you have in the first place and thus it is unclear if your security measures are sufficient or not.

Fully protecting against a malicious user using your application is not possible as long as you are not able to fully control the device of the user. This risk includes running the application on emulators but also includes running it on rooted or otherwise tampered device - and not all of this will be detected by whatever root detection method you use.

Instead you need to design your application so that a malicious user cannot do any harm to you or to other users but only to himself. This for example means having user specific secrets in the application and not using global secrets. This also means that you should not trust anything the application reports but instead verify if this make sense (i.e. not trust any self-reported high score in games or similar).


Configure Firefox against malicious 302 redirect from a embedded image resource? Today my friend demonstrated such a attack.

I am using RenRen, a social networking website in a way very like Facebook in China. And I saw an article he wrote. Actually there is only an "image" embedded in this article, like this:

<img src="http://somesite.org/x.php" ... >

When a browser tries to request this URL, the headers of HTTP is a 302 temporarily redirect, and the destination is the logout page of RenRen, for example:

www.renren.com/logout.do

I know that allowing such an image existing in an posted article is the failure of RenRen's programmer. But instead of telling them to fix that, I want to configure my browser to against it. Some browsers like Safari, as I known, is resistant to such an attack, possibly because it does the MIME type checking. But I have not found a similar solution in Firefox, even not the right plugin. It seems that NoScript with appropriate configuration will do, but I am still not sure.

Therefore I would like to known, how to classify this kind of attacks, and how to prevent it----not only for Firefox...

You cannot defend proactively against this class of attacks. Consider:

the source file contains a http URL.

You cannot tell whether it is malicious or not.
You don't want to prevent it from being loaded (it would block the attack - but would also make several legitimate image repository sites worthless).

you then have to request that URL.

the logout action is activated upon request, so when the browser receives a HTTP/200 OK text/html page saying "You have been successfully logged out", even if it refuses to display it, the command has already completed.

You can organize things so that the attack fails, though.

You could purge all session identifiers from any request as soon as you hit a Redirect, so that the logout page does no longer recognize you. This might be doable with a Firefox extension. This way, you would have:

lucifer -> renren:   get me the message
renren  -> lucifer:  there is an image here
lucifer(*) -> somesite: get me the image
somesite-> lucifer:  go to renren/logout
(the request thread drops the cookie jar and becomes anonymous)
anonymous->renren:   get me the logout
renren->anonymous:   logout who? Error. Cannot logout.
(the request thread expires)

(*) actually your cookie ID with renren is not sent to somesite, since it is likely in another domain.

This could lead to malfunctions in some AJAX applications and possibly OAuth implementations, though; I'd need to check this out.


How to harden Adobe Acrobat and Acrobat Reader I found this recommendation by the CISA to disable Javascript in Acrobat Reader. Also, this article recommends to disable Flash and Multimedia, and the opening of non-PDF attachments. Both recommendations are from 2010.
What more steps would you add to harden Acrobat/Acrobat Reader in 2021?

Disabling JS is actually a very good idea. If you still want to add some extra protection I would recommend:

Set the security options to the highest level. Acrobat Reader implements a sandbox mode, which is called Protected mode and is usually enabled by default. You can also enhance it using the Protected View:

https://helpx.adobe.com/reader/11/using/protected-mode-windows.html

Use an up-to-date version of Acrobat Reader to avoid n-days and vulnerabilities which could undermine the security of the product


honeyd is still a good alternative? I've been investigating to deploy a honeypot for research purpose, Honeyd seems like the most popular and adequate option to my needs, but it seems too old, the last version of this software was launched almost seven years ago (2007) and makes me think if it's still a good honeypot solution.

I would like to know if there are other solutions as Honeyd was in his time, or it's still the best option?, what are the new tendencies in Honeypot? and what are the most common ways to deploy a research Honeypot?.

I need to deploy a honeypot inside a network that is attacked, most common attacks are port scans, NETBIOS SMB-DS Session Setup, SNMP request, ICMP, etc. But there are more than 400 types of attack.

I would also like to integrate this honeypot with a currently deployed snort, for optimum data collection, what could be the best choice? or can i integrate different honeypot solutions?

Thanks ahead...

I have used an ssh honeypot on a VM in my internal networks. It's a specialized honeypot that gives me information on 2 areas:

Anyone attempting to log in on port 22 is a bad actor and I can correlate the connection info with my traffic logs. I can also see what credentials are attempted to see what accounts might be compromised.
Once the user logs in (it always lets them in), it records all keystrokes the user types, which is very useful in gathering data on the intent of the attacker as well as the level of sophistication of the attack.

For my needs, a high interactivity ssh honeypot works very well because the data it provides is useful. You need to choose a honeypot based on the data you hope to get and how you plan to use the data.

What I don't see from my chosen solution is attacks against other services like http, email, etc. It all comes down to what you want to protect.


Klein and PTW wep attack I'm working on an implementation of Klein's wep attack.

For that, I've set up a router with wep encryption and collected 50,000 unique IVs from it.
I tried only calculating K[0], meaning - the first byte of the key.

I run on all my IVs and calculated the equation as the paper says while keeping a record of the number of times each calculated value was repeated. And finally I am printing the top 30 results.

My problem:

The correct first byte of the key is not in one of the first 30 results.
I keep getting negative numbers as keys.

Maybe there is something wrong with my calculation? Maybe I'm not understanding the algorithm properly?

I will put my code here if needed, but since the calculations are fairly simple, I think there is something else wrong.

I am using this as reference:
http://www.item.ntnu.no/_media/people/personalpages/phd/anton/kleins_and_ptw_attacks_on_wep.pdf

I'm not a crypto expert, but I have looked into attacks on WEP.  Assuming you've implemented the calculations correctly, there are two possible issues I'm aware of:

Some keys are unusually difficult to crack, requiring far more IVs than normal.  You may have picked one of them.
The attack is a known-plaintext attack.  Traditionally, the attack is performed using ARP packets because they can be identified easily and have a known prefix.  The attack won't work if you've got more than a few non-ARP packets mixed in with your ARP packets.


How to verify a password/key on subsequent key derivations The first time a user logs in to our app, we derive an AES key from their password using PBKDF2. The AES key is kept in RAM only and used to encrypt and wrap other keys and data during the session.

When the current session ends, we throw away the key but keep the encrypted data and the derivation settings (salt/iteration count/etc.) for next time.

On subsequent logins, we re-derive the key based on the password and settings, but want to check the key (password) is valid (to some reasonable level of confidence) before attempting to use it.

We don't want to also compute a hash over the password because the key derivation is already (deliberately) long-running and we don't want to make that process longer with another long-running hash algorithm.

I've seen a few solutions to this but I'm wondering if there is any standard that should be followed. What I've seen so far:

In Cryptography Engineering, Schneier et al suggest taking hash data from the n-1th iteration of your derivation function and hashing that with the salt, password, etc. to form a verification code. You can store this, and compute the same code for the candidate while you derive the key. If they don't match, you reject. Downside: If using third-party crypto libraries, it probably won't be possible to get access to the internal state of PBKDF2 to do this.
Compute something like SHA256(key+salt+password) and store that. Compute for the candidate and reject if they don't match.
Use the key to encrypt something with a known pattern or suffix, and store that. e.g.

E(key, <32 bytes random data> + <32 bytes of 0>`.

Store this, decrypt using the candidate key and check if the suffix matches. The number of 0s you choose determines the chance of a false positive.

The latter seems simple and effective, but I'm looking for clear advice from an expert/authority on the matter.

Normally, when you encrypt with a symmetric key, you also want to include some integrity check (a MAC) to detect alterations. There are very few attack models where attackers who can observe data cannot also modify data, so some sort of integrity check is normally needed.

The integrity check can be a stand-alone MAC algorithm, typically HMAC; or it can be integrated into the encryption mode (as in GCM). The latter is highly recommended because assembling an encryption system and a MAC securely is a lot more tricky than usually assumed (e.g. see this).

Assuming that your encryption system includes an integrity check, then the natural and safe method for verifying the correction of the password, in your situation, is to keep an encrypted small file with conventional contents -- decrypting the file entails verifying the MAC, hence the password (indirectly).


Synology logs SMB "Read" event false positives We recently switched to a Synology enterprise setup at work and we're hoping to benefit from the additional logging that comes with Synology software. In response to a security incident, I found log entries that suggested a user accessed a file over SMB they may not have accessed.
To prove the theory, I mounted a SMB share, and navigated to a directory. From both Windows and Mac, I found that Synology generated "Read" events for files in the directory (image files, csv files, pdf files, etc) even though none of the files were read.
The problem with that is a user could easily be accused of accessing files they didn't access. Simply navigating to a directory could result in a user "Read" event log. On the surface it may seem like the solution is simple: never restrict access by files, always restrict by directory. But my concern is more about not being able to trust the logs and not knowing what options exist where a user can connect to an SMB share and the security team have reliable event logs.
How do you deal with this type of problem when doing security audits?

Your file manager probably reads the files to find metadata - such as Office document tags, EXIF thumbnails and so forth. You have no way of differentiating such automated reads from a user opening the file on this level.
To me it sounds like a X-Y problem. What do you want to achieve? An audit trail whenever a user opens a file?


How to protect from dependency confusion attacks? I recently came across following article
https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/
it describe about an exploit which exploit design flaws of different package managers ex: package manager preferring higher version numbers, public packages over private ones
But article does not provide any details on how to mitigate these type of attacks? Big companies seems to have implemented mitigation strategies according to the article.
Anyone more knowledgeable please share how protect from dependency confusion attacks when using package mangers like NPM, Pip, Maven, Gradle, RubyGems, Stack.

Microsoft published a white paper describing a few mitigation strategies. To summarize them:

Make use of a single dependency source instead of multiple: The idea here is to configure your package manger (e.g. via the pip config file) to only pull packages from a singular repository you control or trust. I guess in the "best" case you'd restrict it to a private repository you manage and mirror/copy over packages you need from other sources. There are some real downsides to that though (keeping third-party packages up-to-date is one).
Use something called "scopes" where applicable: Many package managers have a concept of "scopes" (e.g. https://docs.npmjs.com/cli/v7/using-npm/scope) where packages can be assigned a prefix that is unique to the controlling organization. This is especially useful if you make use of internal packages. Even if you don't plan on publishing them, you can register an organization and then (internally) make sure your package lists always use your organization name "scope". I believe yarn v2's workspace feature can be used to mitigate this as well.
Use client-side features to reduce the probability you will accidently upgrade to a malicious version. Some examples here are version pinning (e.g. "8.9.x" instead of ">=8.9") and integrity verification (npm ci instead of npm install)

3 is not a strong guarantee in my opinion, but is easy to do. 1 is sometimes a good option, but can be hard to implement/maintain. 2 is probably the "best" option, at least for preventing your internal packages from being compromised this way.


Authentication with an untrusted server I asked a related question earlier, but I want to ask a broader version this time:

To simplify things let's say I've developed an application that allows users to send messages in a chat room, and to each other (similar to IRC). The nature of the message doesn't require too much secrecy, nothing sensitive is ever shared.

I develop an open-source server and an open-source client for the application. Users will setup their own servers, I simply provide the server and client programs.

I want users to have accounts on each server. The client should ideally log on with a username and a password.

I can assume the client won't steal account information because the user got it from a trusted source. The problem is the server can't be trusted because:

Each server's owner can make modifications to their server's code.
They can see the contents of any database.

How can I authenticate users:

without letting the server owner access the user's password
without letting the server owner access a precursor to a user's password (anything that isn't the password, but can either be turned into the users password, or used to log into another server).
without relying on an precomputed key that has to stay hidden on either the client or server (the source code would reveal it).
ideally allowing a password
Edit: Ideally the password and username would be all it'd take to log on, so logging on with different machines the user would only need the password and username.

The approaches I have in mind:

Challenge-Response: Send a challenge, hash it with a password, and send it as a response. This passes requirement numbers 1 and 3, but fails the 2nd, as it requires the server to also have access to the hashed password, which can be turned into the actual password, or used to log onto other servers (the latter is slightly lesser, since it can be dealt with if it occurs). My other question goes into details on how I implemented this idea for testing.

2: Server Whitelist: This feels a little like cheating, but it meets all the requirements by "removing" the biggest issue, the fact the server can't be trusted. If the client tries to connect to a server not on the whitelist, a strongly worded warning would be issued(or access to non whitelisted servers could be completely blocked). This has the downside of complicating the process of users creating new servers, and it places more responsibility on me than simply developing the application (I'd have to manage the whitelist). It also doesn't necessarily ensure that the server can be trusted since even if the owner isn't malicious, there's no guarantee they have proper security on their systems.

It sounds like you want public-key cryptography similar to what SSH supports.  The basic idea is that the user provides their public key to the server during the account creation process, then proves their ownership of the corresponding private key during the login process.

The public key, as the name implies, isn't even remotely secret, so it meets requirement 1, it can't be used to construct the private key, so it meets 2, it's computed at account-creation time, so it meets 3, and yes, you can use a password to protect the private key.


When GeoTrust CA issues certificate for the domain Google, does it also provide private key to Google by which the certificate is digitally signed? I've already addressed this link How does SSL/TLS work? before I posted my question but I couldn't find there what I'm asking here so it's not a duplicate question.

GeoTrust is a certification authority which issues digitally signed certificates to registered domains. Every year they issue millions of certificates for registered domains. But on issuing a certificate for a domain, does CA also provide private key to that domain for whom the CA certificate is being issued and digitally signed? Do the public and private key for a particular domain match with other domains?

If CA keeps private key as secret while signing the certificate then how servers decrypt symmetric key because public key is used for encryption and private key for decryption and that private key has already been used to digitally sign the CA certificate(Am I wrong?).

In my question I've taken GeoTrust as CA and Google as domain for just an example because I know there are other CAs like VeriSign, Symantec etc.

In theory a CA does not even see the private key of the certificate it issues. To get a certificate issued one first creates a key pair and based on this key pair a certificate signing request (CSR). This CSR only includes the public key, not the private key. This CSR is then used by the CA to create a signed certificate which includes the public key. There is no need for a CA to have access to the private key of the new certificate at any time.

In practice some CA allow the user to create the key pair online and could thus in theory have access to the private key because they control the code how the key is generated. This is only to make it easier for technical less capable users. But probably no CA requires the user to proceed this way, i.e. they offer a way to create the key in private and only upload the CSR.


Does this show the need for a two-factor authentication? I need some help for my understanding while reading through this authentication scheme in WEP.

In a WEP authentication scheme, the station first sends a request for authentication. However, this authentication scheme is a one-way authentication because it does nothing to prove to the station that the access point knows the key. Does this show the need for a two-factor authentication and the importance of a two-factor authentication?

Thanks very much!

"Two-factor" is not "two-way".

"Two-way" authentication, aka mutual authentication, is when two entities (let's call them A and B, e.g. a WiFi access point and a client system) prove to each other that they are who they claim to be; A gains confidence in the fact that it talks to the genuine B, and B gains confidence in the fact that it talks to the genuine A.

"Two-factor" authentication is when one entity proves its identity to the other twice, using two methods which are qualitatively different. E.g. A shows to B a password and a code which B just sent to A's mobile phone (with a SMS); this is "two-factor" because A's password is bound to A's brain (that's "something A knows"), while the code over SMS is bound to A's phone (that's "something A owns").

The two notions are orthogonal to each other.


Should programs check for symlinks before creating files? We received a bug report (phrased as a security issue) for a program, which stated that when the program creates files on disk, it does not first verify if a symbolic link exists at the file path to be created. Because of that, an attacker may create a symbolic link, which the program (when ran by another user) may try to overwrite, thus overwriting a file that the attacker may not otherwise have write access to.

To illustrate, here is an example with gcc, which is also "vulnerable" to this problem:

Eve sends Alice a .tar.gz file containing a C program. Inside the archive is evil.c, and a.out, which is a symbolic link to /home/alice/.xinitrc.
Under some pretense, Eve asks Alice to compile the program (and do nothing else).
Eve runs gcc evil.c, which by itself should be safe (barring buffer overflows etc. in the compiler).
gcc (technically the linker) will try to write the resulting binary to a.out, thus overwriting Alice's .xinitrc.
Next time Alice starts her X server, Eve's code runs.

In our case, the situation is very much like gcc - the program creates files only under the current directory (unless told otherwise), with predictable names, and does not by itself execute any code from its input.

Is this something that programs such as compilers need to worry about?

Yes programs should pay attention to symlinks if the programs read or write files from/to directories where users with lower privileges can create symlinks. Otherwise it is possible that a user can read from or write to files which should be protected.

But you should avoid a check like if(!issymlink(path)) { writeto(path) } because that would be prone to a race condition. Instead in linux, for example, you can use the O_NOFOLLOW flag to open to fail with an error if the path points to a symbolic link.


Is arbitrary code execution possible using GOT overwrite with W^X enabled? Is it possible to reliably execute arbitrary code from a single overwrite of the Global Offset Table when W^X is enabled?  By "reliably" I mean assuming I control only the location pointed to by the instruction pointer and possibly some non-executable data elsewhere.

Why I ask: using the House of Force heap exploit demoed here, it is possible to overwrite arbitrary memory, which makes the GOT an attractive target for hijacking the instruction pointer.  However, to make that implementation of the heap overflow work (i.e. get a shell), the author had to inject shellcode to point to from the GOT.  If W^X is enabled, this technique would fail.  Is there a method (possibly leveraging ROP/JOP?) that overcomes this limitation?  The reason I'm having a hard time with this is because in this exploit you only control the instruction pointer, not the stack pointer, so I can't easily see a way to make ROP work, and JOP seems to require control of multiple registers to make it work (but to be honest, implementing JOP is still over my head).

W^X simply prevents pages from being both executable and writable simultaneously, so an arbitrary write vulnerability cannot modify executable pages. It does not enforce control flow, so any exploit primitive which permits out-of-order execution of existing code has the potential to bypass it. Other attacks such as SigReturn-Oriented Programming, or SROP (on platforms which are vulnerable to it) and Loop-Oriented Programming, or LOP, are often capable of achieving the same thing.

An example JOP exploit can be seen here.


Can apps be trusted when requesting your credentials? I recently bought a newsreader app for my tablet that connects to Google Reader. To do so, it required my Google account password. Isn't this effectively the same as handling the password to the developers of said app? I wouldn't care about someone else reading my feeds, but this could be used to access my private email as well... Isn't this an extremely efficient method of gathering passwords and a terrible security risk for users?

Can apps be trusted when requesting your credentials?

No. In modern applications and web applications users have become numb to the requests for username, password, and various other innocuous details. The commonality has led users to believe that these information nibblets are useful to the application. However, this is wrong. With rare exception, authentication is unnecessary to application function.

In fact I believe application use of authentication is detrimental to the user. It makes authentication too common, making users less prudent and careful in cases where authentication is needed. It structures the identity space making it easier for attackers to guess your identity. It simplifies the keyspace making it easier for attackers to find your keys. It dampens operation security and degrades security practice for assets with value.

  Isn't this effectively the same as handling the password to the developers of said app?

Yes, with rare exceptions. Even in cases where the protocol is not directly delivering the password to the application or developer, but is instead delivering an authentication token, the potential for misuse and abuse is high. Even OAuth has vulnerabilities 'This protocol makes no attempt to verify the authenticity of the server.'.

  Isn't this an extremely efficient method of gathering passwords and a terrible security risk for users?

Yes, even when it is unintentional, poorly designed authentication schemes can provide a wealth of information for attackers. Even if the username and password you use for a typical application is not the same as the username and password you use for more important assets, the patterns you use help attackers narrow in on the valuable authentication. In contrast, well designed protocols like OAuth have a bright side: they reduce the number of pairs of usernames and passwords, as well as the number poorly design, poorly implemented authentication interfaces.

However, we also need to look at the OAuth service providers: Google, Yahoo, and Facebook. These are companies with an interest in collecting and aggregating information about users specifically to make money from that information. Using these companies as authentication providers is in part a bizarre contortion of trust. You are trusting these companies to handle authentication of your identity only to parties you specify. While they have a conflicting interest in providing data about you with as high resolution as possible to parties your are unaware of. Their most effective claim is that the information they provide about you to third parties is anonymous. They hold that this will be true despite the fact that they now know your identity and have authenticated it, potentially many times. I have been unable to find any policy specifically stating that these providers will never allow your authenticated identity to be connected to other collected. Caveat emptor.

The application in question: 'newsreader app for my tablet that connects to Google Reader'

The purpose of this application is to monitor no-cost publically available online content (web sites and RSS feeds) for new content, to notify you when new content is detected, and to display the content on request. The online content is not unique to you, meaning that you do not need to identify yourself to obtain the data.

The data that is unqiue to you is the list of sites and what content you have marked as not-new. Uniqueness requires identity but not necessarily authentication. The application uses Google Reader, although it could simply implement its own functions without the need to use Google Reader. Likely the application is doing this to keep your data coherent (synchronized). You want to be able to check online content from a number of different devices and not need to manually update changes on one device that you made on another. Note that the application could still synchronize with other devices without using Google Reader.

Your unique data (site lists and read-content) is transfered to and from your device. Authentication does not provide confidentiality (privacy). So authentication is not protecting others from seeing your site lists and read-content. Authentication does not provide integrity, so your data could be corrupted or maliciously modified while in transit. What authentication provides is a way to control the reciept and storage of the data. If the data is from you then it must be valid and thus an update from your current device to all your other devices should be accepted so your data is kept in sync.


When would group permissions be a security issue? I frequently hear that 600 and 700 is recommended for security when possible before 660, 770. I'd like to understand the risk that 660, 770 would have that 600, 700 wouldn't.

The principle at play here is the least privilege.

A chmod permission of 600 or 700 gives only the owner rights to the file, while 660 or 770 gives the same rights to the group too.  Whether this is intended or not depends on the use case.  Either might be appropriate.

A server might - and will probably - have different categories of users (students, guests, employees, administrators ...). Keeping privileges separated is important in this case.

The possible problem with 660 and 770 is that a sysadmin might inadvertently add an extraneous user to the group in question, hereby giving the group-crashing user the same rights as the owner.

It is worth noting that nowadays group permission in Linux are obsolete (they've been replaced by ACLs), and by default an user is assigned only his/her group.


What are the benefits and risks of various TLS Handshake protocols? This question asks if it's possible to separate the rest of a TLS session from the handshake for "security reasons".  The question wasn't specific on what that "reason" might be.

This made me research the various TLS handshakes to determine if there was any benefit (DOS attack, or cryptographic oracle) that would be defeated with such a configuration

Some basic research tells me that the following handshakes exist:

SSL 2.0 unprotected handshake allowing for a downgrade
Typical TLS 6 step handshake
TLS 1.1 RFC 4346
1-RTT in TLS 1.3
0-RTT in a future version of TLS (draft in TLS 1.3)

Question

How many TLS handshake protocol variations exist?
Is the list above each considered a "handshake" or can they be grouped into primary and sub branches?  (e.g. X is a minor variant of Y, but Z is completely different)
What is the notable difference between the TLS handshakes?

Depending on how you see it, there is one, two, three, or many more "handshakes".

A first distinction is between "SSL-2.0" and "SSL-3.0 and later". The format of records and handshake messages for SSL-2.0 differs a lot from the records and messages used in subsequent protocol versions. Apart from the format and the implemented algorithms, a notable semantic difference between SSL-2.0 and the later protocol versions is that in SSL-2.0, both client and server send lists of cipher suites, and the client chooses, not the server. In later versions, the client sends a list, and the server chooses.

When doing a SSL-3.0+ handshake, the client sends a ClientHello message, and the server responds with a ServerHello. The ClientHello may contain many extensions, which are (by definition) open-ended, and it is up to you to consider whether extensions "change" the handshake or not. In any case, if the client and server agree to resume a session (either they reuse a session ID and remember the past session, or the client sends a session ticket, then you get the abbreviated handshake:

  Client                                                Server

  ClientHello                   -------->
                                                   ServerHello
                                            [ChangeCipherSpec]
                                <--------             Finished
  [ChangeCipherSpec]
  Finished                      -------->
  Application Data              <------->     Application Data

In all other cases, you get the "normal" handshake, that looks like this:

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

The "*" above means that the message is not always there. For instance, the server will send a ServerKeyExchange only if the cipher suite calls for such a message ("ECHDE_RSA" implies such a message, while "RSA" alone does not).

So this leads to a number of possible combinations of messages sent or not sent. Moreover, a number of extra RFC define some extra messages, that do not appear in the diagram above; e.g. RFC 5077 defines a new handshake message NewSessionTicket that may occur just before a ChangeCipherSpec from the server. Similarly, RFC 6066 defines the new message types CertificateURL and CertificateStatus. RFC 4680 also defines SupplementalData that both client and server may send to each other.

How you choose to classify all of these features, and whether they induce notable differences, is up to you. Moreover, there cannot be a definitive, exhaustive list of variants, since new extensions that trigger new message types or new handshake flows can always be defined afterwards.


Ciphertext vs database level encryption For data that must be encrypted (read again, not hashed like a password) does storing ciphertext in a database gain you much over using the database's built-in encryption?

In this case it would be ciphertext generated by attr_encrypted vs PostgreSQL's pgcrypto module. I would think it protect data that was obtained from SQL injection or database access as long as the key remained safe?

The ciphertext downside being you lose the ability to query the data, so if it's only security theater it seems better to use the built-in database encryption.

...does storing ciphertext in a database gain you much over using the database's built-in encryption?
I would think it protect data that was obtained from SQL injection or database access as long as the key remained safe?

No.
SQLi can be used to quickly escalate access to the rest of the machine.
Form the pgcrypto docs you list:

F.25.6.3. Security Limitations
All pgcrypto functions run inside the database server. That means that
all the data and passwords move between pgcrypto and client
applications in clear text. Thus you must [either]:
-Connect locally or use SSL connections.

-Trust both system and database administrator.

If you cannot, then better do crypto inside client application.

This means that if an attacker can get into the machine, your data is exposed.
As they suggest, if this can not be ruled out you can do one of two things:

Move the application to a separate machine so the key is not on the same machine as the database
Encrypt the data in the client application.

The ciphertext downside being you lose the ability to query the data.

Not entirely. Here is a guide on indexing encrypted data in SQL


HTTP over GPRS - is it secure? I have project involving a M2M device. The device is not capable of HTTPS but may be required to send and receive information that we would rather not be leaked out.

The device will communicate directly with a webserver, what are the possibilities of a hacker identifying the the origin of the data and intercepting any transmitted information. If it is relatively simple would a private APN be more secure.

GPRS does not provide strong protection of the data.  There is some cryptography applied on the wireless link between the mobile device and base station, but this cryptography has significant problems (see research on GSM and more research).  Also, once the data reaches the core network, the data is transmitted in the clear, unencrypted, for the rest of the way.

Consequently, I recommend that you set up a VPN and tunnel all your traffic over the VPN.  IPSec is a good tool here.


Reflected XSS monitoring There is a lot of information on how to avoid or detect XSS, but I couldn't find much information on how to monitor for reflected XSS. Is there a way to automatically detect reflected XSS in my application's logs?
My guess is that we can run a parser on the logs and signal all the possible reflected XSS attacks. Is there a library already that does this?

There are manual approaches and tools to analyze your logs (see eg here); but listing tools themselves would be off-topic here.
The problem with these approaches is that you are not monitoring for suggessful XSS attacks, but for attempts. This can also be useful to know how attackers are attacking your application, but there will be a lot of noise from automated scanner, etc.
It doesn't seem like this is what you necessarily want though. If you actually want to monitor for successful XSS attacks, you may want to consider using the reporting feature of CSP. You can also use it as report-only without negatively affecting usability of your application.


Is it safe to let the user name an object key in JavaScript? Recently I found a piece of code that takes input from the url. The input then get's saved into a javascript object:

https://website.com/?foo=bar

var x = {"foo": "bar"};

While the value doesn't allow opening and closing brackets the key does. Single and double quotes are properly handled in the key and are completely removed in the value.

Is this a potential security risk or is it safe to implement something like this?

Is it safe to let the user name an object key in JavaScript?

It is somewhat dangerous and not always correct to use user defined properties on Objects. It is typically recommended to use a Map object (in recent browsers) or some of the custom libraries to emulate it.

Some pitfalls are described here: http://2ality.com/2012/01/objects-as-maps.html


How does the error message "Incorrect username or password" prevent user enumeration? I see that almost every website and service won't tell you if you got your username or password wrong but wont tell you which one.

The reason I always see for this is it allows an attacker to work out which users are in the system, but for almost every website I can already work this out by visiting the profile of that user which will either give me a 404 or show the user page for that user or I can try to sign up using an email which will tell me if an email/username address is already taken often even before hitting submit.

Why is it that these services which allow easy lookup of user IDs still try to hide the fact that the username exists when you sign in? From my perspective it almost seems like this is a similar situation to What technical reasons are there to have low maximum password lengths? Where in one case something was helpful and then everyone copied it to the point where it was used outside of it's helpful situation.

Obviously, if there are other techniques for enumerating the users, then having the single message is of little use.  But many forums only allow you to see user profiles once you are logged in, and if the forum is invite-only, then you would not be able to use this.  Most likely, they are designing the login system for any case/combination of login system.

Naturally, in higher security applications (banking, etc.) steps are taken to try to ensure that there is no way to enumerate all users on the site, both through the login form and through other mechanisms on the site.


What is the difference between SRVHOST and LHOST in metasploit? What is the difference between SRVHOST and LHOST in Metasploit.
I am testing an exploit in my virtual lab of which I had to set both options. LHOST was an option for the payload selected, while SRVHOST was included among the options to be set for the exploit. I believe SRVHOST and LHOST should be the address of my computer. I then tried giving SRVHOST a wrong IP-address and LHOST the right IP address, and the connection back to my computer was successful; but if I gave LHOST a wrong IP-address and SRVHOST the right IP-address, the reverse connection failed.
Why then do I need the option SRVHOST since LHOST performs the same function in my payload?    and
Practically, how can SRVHOST be used?

SRVHOST is generally the option that you set when you are serving a exploit on a web server and LHOST is the option you would set if you were using a exploit that is not going to be served on a web server.


Help identify a simple, reversible cipher/encryption algorithm I'm trying to help a small business transition out of an obsolete, obscure piece of software, and app support is, unfortunately, non-existent. To fully export the data for the new system, I need to be able to decrypt/decipher a string in one of the database fields. But cryptography is not my specialty and I have not been able to reverse engineer what seems to be a very simple encryption/cipher algorithm.
I can create plaintext strings using the app, then see what they look like encrypted in the database. I can copy the encrypted string from one database record to another and it still decrypts just fine no matter which record I open in the app. This suggests to me either the method is keyless, or it's a static/hardcoded key which is always the same. It smells like some kind of XOR method but I can't fully put my finger on it even though analysis of the input and output has provided significant clues.
More clues: The application is for the Windows platform (32 bit), apparently coded in VB6. It's built on a code base that was first released in 2001, and version updates have been incremental and backward-compatible, so I surmise the current version is derived from that original 2001 codebase. That means the encryption method is likely of that time (2001); newer encryption methods can likely be ruled out.
The encrypted output is always a hexadecimal string with a length which is a multiple of 16. For example, a 1-to-7-character input produces a 16-character hex output. An 8-to-15 char input produces a 32-char hex output. A 16-to-23 char input produces a 48-char hex output. Note that while some of the sample inputs are numeric, they are strings.
Notice also that some of the output hex strings have the same endings or beginnings as others despite their inputs being different.
I am sure someone with a bit more experience than myself can sniff out the encoding algorithm in a jiffy. So here are some sample plaintext inputs and encrypted/ciphered outputs. What can you tell me?
Samples:
INPUT (PLAINTEXT STRING)   OUTPUT (HEX STRING)
=================================================================
0                          3603B5C0D407A6FF
1                          9034469951F9BDB6
2                          101080C2FB110A89
0000000                    8AB449F106D5F76A
00000000                   87E0460F100F7E5B7783D03238923053
000000000000000            87E0460F100F7E5B8AB449F106D5F76A
This is a sample string.   D9E1588915C9B1E00D688CBCA066B18D70DC39F1072896F77783D03238923053
Hello, world!              108350BBCE7441DB9BB6235DADC206B5
Bazinga!                   2C03D5CBAAEA807D7783D03238923053

I would be happy to supply any other sample input/output by request.

It looks like DES.
Arbitrarily using a Key of hex    0000000000000000
and an initialization vector of   0000000000000000

The value 0000000 becomes  01a4f7bc5f3aa9ee
but value 00000000 becomes de8d55142b18deb7472b8bbb294d3f3d

I have no idea as to the correct Key and IV.


Mobile Phone Client -> Server Authentication based on device I have a mobile application (Android, iOS) and a server, which handles requests from the application.

It is easy to perform standard authentication using SSL, password and random token to authenticate the user.

However, I have no idea how to authenticate the mobile device AND the user. I need to prevent the user from using other devices then the one he used for the first time (for some very good reason).

The problem is I must expect the user will not cooperate. On contrary, he will probably try to use another device, but I have to stop him.

I think the SIM card must be the key to this problem. However, I cannot make any changes to SIM card itself (I cannot install any special SIM applet to the SIM). I can use only the features ANY SIM card provides.

Is there any possible solution?

In mobile app -> server scenario, I like to have an approach for each of the following identity

User Identity - i.e. person trying to initial transaction with your server
Application Identity - application being used by user to perform the transaction
Device Identity- the actual device being used.

Each of these are important part of the comprehensive identity management. In your case, device Identity is the focus. There are a lot of device specific information like SIM card ID, IMEI, UDID (in case of apple) that can be used to tie a specific device to a user.
An alternate approach can be that at the time of initial registration of the device, you can generate a public and private key pair on that device. You can associate the public key with the user id on your server. Now, every time you initiate the session or perform transaction, you can use the private key to sign a token (e.g. JWT) and send it with request. As part of authentication/authorization process on server, you can validate the token received and match it with authenticated user id based on saved association.

In addition to that, I am assuming, you have good process in place to handle
1. Transfer of mobile device - people sell or give their devices away and new people want to use device to run your application (with or without device wipe).
2. Multiple users - people in same family may use the same device but different user id to perform transactions.


Secure preshared key 2 way authentication I have the following setup:
A server and a client will be connected over tcp. The server and client both have access to the preshared secret key. When the client connects to the server, the client and server both need to know the key, so they need to use the same key to authenticate or it will fail.
I came up with the following process and would like to know if there is anything obviously wrong with it that I didn't see. The actual encryption is not
relevant in this case.
So this is what happens when the client connects:

Server generates a 16 byte salt (salt1).
Server calculates hashServer1 = HASH(key + HASH(key + salt1)).
Server sends salt1 to client.
Clients calculates using the received salt1 hashClient1 = HASH(key + HASH(key + salt1)).
Client generates 16 byte salt (salt2).
Client calculates hashClient2 = HASH(key + HASH(key + salt2)).
Client sends (hashClient1 + salt2) to server.
Server checks if received hashClient1 == hashServer1 and if not breaks.
Server calculates using received salt2 hashServer2 = HASH(key + HASH(key + salt2)).
Server sends hashServer2 to client.
Client checks if received hashServer2 == hashClient2 and if not breaks.

If I am not mistaken, this should be pretty secure when using a strong hash algorithm. The key is never send as clear text and due to the salt the data is different every time.

EDIT: Changed the salt used for hashing from saltX to HASH(key + saltX).

The only glaring problem I see here is that the salt is effectively useless. The point of a salt is to make cracking more difficult by adding an extra unknown factor to support the entropy of the hashing process. Salts do not necessarily need to be secrets, but we do want them to have a few properties when it comes to securing hashes:

never reuse salts
dont give salts out for free
dont use short salts

giving the salt each transaction will allow me to watch for patterns in their creation. of course, this depends on how true to random their generation is.

In this case if I'm an attacker sniffing this traffic, I have the salt every time. meaning I have effectively reduced the problem to cracking the PSK in every single case, and you provide two hashes and salts to me every connection, further increasing my pool.

This is still a big problem, I still have to see if I can find the value that leads to the hash you give, but in this case, once I have one hash+salt pair, I'm just cracking the PSK at that point.

I think the most important things here are that salts are usually used to protect large databases of information from reverse lookups or rainbow tables. But in your case, your entire server is subject to one password. Knowing the salt is a bigger deal here, and I would wager that makes the salt a secret even. Something worth guarding. Since if I really wanted to get in, I'd take one salt/hash pair and generate hashes until I found the PSK.


Security configurations to protect against 0-day exploits? Let's say someone has sensitive information on their computer and can is a potential target of 0-day exploits/attacks.

Assuming that they follow conventional security advice (using a firewall, antivirus, encryption, and an updated operating system), are there any other ways to help defend or protect against 0-day exploits and attacks?

Unfortunately, the risk with 0-day attacks is that you don't know what they can do or what they will do. Even if you have an up-to-date operating system, firewall, antivirus, and even full-disk encryption, a fault in any of these could potentially give an attacker access to your system and your data.

With that in mind, discovering 0-days is always a race between the good guys and the bad guys. The bad guys want to find vulnerabilities and exploit them, while the good guys work to patch any suspected vulnerabilities through constant code reviews, audits, and penetration tests.

One argument that could be made is that software released from trusted vendors like Microsoft, Apple, or Google is that, because they have obscene amounts of money to throw at security, their software is much less likely to have vulnerabilities than the average third-party application. And even if a malicious hacker finds a vulnerability in the software, it still takes time to conduct research and develop an exploit that can target computers on a large scale, giving security researchers more time to find and fix the issue.

But ultimately, the fact is that no computer is 100% secure, and Murphy's law holds true. Anything that can go wrong will go wrong.

If this is a matter of secure storage, then there is something to be said about encrypting data and keeping offsite encrypted backups, without an internet connection with which hackers could use to exploit a system and get to the potentially encrypted data. Or there are always type-writers and safes. But conventional software and IT security can only go so far, especially when dealing with the unknown.

Realistically though, the majority of viruses are going to target old, unpatched machines with no firewall. Unless hackers are specifically targeting  a victim's machine, it is much more likely that they will go after the thousands if not millions of unpatched and vulnerable computers out there. And if they are directly targeting the victim, there are other ways of getting information out of them: https://xkcd.com/538/


Time based event, console application on Windows Server -- security implications I'm a software engineer, and I've written several discreet utilities that run at specific times on Windows Server 2008. Generally speaking, they are console applications, need to access SQL Server, are configured for trusted access and are running under a service account.

Our security folks tell me I need to re-architect these since they don't wish to allow local logon to the service accounts. They suggesting I create Windows services which will be run by the service account with trusted access to the database.

As a programmer, running a service that waits for a specific time of day to do some work seems like an anti-pattern, and it's harder to debug issues. But if it's more secure I'm happy to get behind it -- thoughts?

If your applications run at specific times, then they must make some allowance for the fact that they may run at times when there is nobody to see them running. This means that you must have some logging system (e.g. using Windows events, or simply by writing into some files). Your debugging should go that way.

Anyway, though writing your own service is not hard, reinventing the wheel is always wasteful. In that specific case, Windows offers a specific task scheduler which is perfectly able to launch your applications (even scripts or console applications) at configurable times, starting in a configurable directory and running under a configurable account. Moreover, there is a specific local policy (called "log on as a batch job") which controls which account(s) may be used for that. This ought to appease your local security people.

(Of course, in many places, there are people with more power than knowledge, who will force you to perform elaborate somersaults through many hoops because of some irrational fear they have. Though the Windows task scheduler is the method recommended by Microsoft to launch tasks at programmable times, you might have to write your own service because otherwise some guy will go into uncontrollable fits -- and be warned that the same guy will deny everything in the event that the loss of time, flexibility or money induced by this needless re-engineering is noticed by somebody in upper management.)


Would 'zero-knowledge' requests be an secure extension of SOP/CORS? As far as I understand, the Same Origin Policy exists to prevent authenticated requests from other origins.

So when a bad guy builds an evil website which tries to hijack the active authentication of my customers in order to manipulate or steal data on my server, my server can tell my customer's browser, that my server will not accept requests triggered from the evil website origin.

But I am wondering why the browser prohibits (SOP) all cross-domain requests when the receiving server does not respond with the correct CORS headers.

Question: Shouldn't it be safe to let the browser send 'zero-knowledge' requests without the authentication data, cookies, etc., that it knows from previous encounters with the domain? Like in incognito/anonymous browser mode or curl with a fresh cookie file?

That way cross domain communication would still work for servers without CORS headers and browsers would still prevent any authentication hijacking.

No, they would not be.

Your assumption

  CORS exists to prevent authentication to trusted domains

is wrong. Why? See my answer on this question


How would I safely store a password locally? I have a program which allows another authorized user (with a password) to access someone else's computer without them having to be there. However, I don't know how to safely store the password without requesting the user reenter the password every time they launch the program. I have a few ideas, such as hashing the password and storing it to a file, but this could get cracked by a hash cracking program such as hashcat. I have read Safe ways to store passwords without hashing them and have thought about the CryptProtectData API. Would it protect the passwords from another application which is potentially malicious? Or is it on a per application basis?

Would it protect the passwords from another application which is potentially malicious?

No
DPAPI (of which CryptProtectData is a part) cannot protect against a malicious application running under the same user. This is because any application running under the same user can request decryption of a DPAPI encrypted blob. It is possible to give DPAPI some additional entropy while requesting encryption, and then only an application that knows the additional entropy will be able to decrypt the blob, but you run into the original issue again. Where do you store the additional entropy, such that a malicious application cannot access it?
The only situation in which DPAPI offers any real security is if you're device gets stolen (or confiscated by some authorities) and you don't have FDE. In this case, provided that your Windows password is strong enough to resist bruteforce, the stored DPAPI encrypted data cannot be read.
In the end, it's just as @Polynomial says in the linked answer:

Any procedure you choose to obfuscate passwords is an exercise in futility against any half-determined attacker, so at most you're creating an illusion of security.

I have a few ideas, such as hashing the password and storing it to a file

The main problem here isn't that the hash can be cracked, it is that cryptographic hashes are irreversible. So when you need to log in, you won't be able to recover the password from the hash. If you design the application to send the hash instead of the password, the hash effectively becomes the password, and you're back to storing it as plaintext.

Edit: As clarified by OP in comments, the application in question is the server, not the client. For a server, there is absolutely no reason you should store the password in a reversible format. Hash it with a strong password hash like bcrypt or Argon2id and store the hash only. (Warning: Do not try to implement the hash functions yourself. Use a well-known and tested implementation.)


Running an Open Server (contents are visible) I'm considering the possibility of running an Open Server, as I would call it, that is, a server where as much of its contents are publicly visible as possible. I would like to give read access to everyone for as much content as possible. I'm wondering what content on a linux server, such as an Ubuntu one, with the typical Apache, Mysql, PHP setup, would need to be hidden. I can move the database password to another server and transmit it through an encrypted exchange. I can use an NIS system for the system passwords. Then, I'm not sure what else needs to be hidden. It seems I can allow read access for the entire server that way. Is there anything else that would have to remain hidden?

Assuming your server doesn't use any credentials besides system-level accounts and the MySQL password, there's one thing you need to protect: the swap file.  Programs are supposed to take steps to prevent credentials from winding up in swap, but they don't always do so.

There are some sensitive things in /dev and /proc (such as /dev/mem and /proc/kcore).  The proc filesystem driver should prevent you from making dangerous changes to /proc, but in a udev-based system /dev has no such protections, so don't change anything there.

Keep in mind that giving read access to everything means users have read access to the MySQL database by inspecting the files directly.  Make sure any web applications you install don't store credentials (user or application) there.


How is a Digital signature of a X.509 generated? I was asked a question recently at a job interview about HTTPS and admitted my knowledge was fuzzy in the area, but gave a crack at it anyway, the question was how does someone know that when they connect to a server that the person or service say who they say they are? how can you trust them? I answered you will be given a certificate from the CA and this contains information that the connection is legitimate, this was apparently not satisfactory as they then pushed for more asking about how do you know they are who they say they are from this certificate? In my head i thought being provided a certificate from the a CA was enough.

The answer they were looking for was the Digital signature. Which i completely forgot about. Nevertheless, feeling like a complete dolt afterwards i decided to shore up some holes in my knowledge and did me some learnin'.

So to recap (please feel free to tell me if im missing anything)the Digital signature is created by hashing some data on the certificate then encrypting it using the CA private key, which the person interested in authenticating the validity of said certificate will generate a hash on the same data on the certificate used in the signature generation, then use the certificates public key to decrypt the digital signature obtaining the hash, and then comparing them.

Now where Im a little perplexed about is how does let say a client know which part of the certificate to hash to then compare it to the hash retrieved from using the certificates public key on the digital signature. Does x.509 have a standard or do they just hash everything in the certificate? or do they communicate somehow on how they generate the hash?

... which part of the certificate to hash ... Does x.509 have a standard or do they just hash everything in the certificate?

It's all defined in RFC 5280. In section 4.1.1.3. you will find:

  4.1.1.3.  signatureValue The signatureValue field contains a digital signature computed upon
     the ASN.1 DER encoded tbsCertificate.

And to find out what this tbsCertificate is continue reading with section 4.1.2:

  4.1.2.  TBSCertificate
     The sequence TBSCertificate contains information associated with the
     subject of the certificate and the CA that issued it.  Every
     TBSCertificate contains the names of the subject and issuer, a public
     key associated with the subject, a validity period, a version number,
     and a serial number; some MAY contain optional unique identifier
     fields.....

The certificate itself is then the tbsCertificate, the signatureAlgorithm and the signature. Or in a more formally defined way at page 116:

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     ...


Is intercepted ssh-socks traffic revealing HTTP object count and sizes? I read an article titled the network is hostile, in which the following is stated:

  Traffic analysis remains a particular problem: even knowing the size of the files requested by a TLS-protected browser connection can leak a vast amount of information [pdf] about the user's browsing habits.

In the linked article, a the website visited may be identified due to the subsequent GET requests after visiting an encrypted website. The adversary only sees the traffic and is in possession of a database of websites and their subsequent requests (amount and sizes).

Is  this attack  applicable to HTTP traffic flowing through ssh-socks5 connections (with DNS request through the tunnel)? I'm not sure if such a channel is included in the SSL or TLS type encryptions mentioned in the paper.

You can still see the traffic pattern when looking at the encrypted SSH connection, but you don't see the target host of the requests. But if you know what the target host might be you could still do the same kind of traffic analysis - at least if you only have a few connections at the same time.

For a similar kind of flow control analysis but for SSH see Timing Analysis of Keystrokes and Timing Attacks on SSH. In this attack you could reduce the scope of possible passwords a user is entering within an established SSH session by measuring the timings between the packets containing keystrokes. While in this case on could use random packet delays to disrupt this analysis disrupting analysis of HTTP 1.x traffic is much harder because it has a typical pattern with (usually small) requests followed by (usually larger) responses, then the next request and next response etc. And both the directions and the approximate size of the requests/responses can be seen when looking at the SSH traffic.


How does the Subterfuge toolkit bypass SSL? As the title says, does anybody know how Subterfuge bypasses the SSL layer?

Subterfuge is a Man-In-The-Middle tool kit that allows you to intercept communication on a LAN. Generally this is done by ARP Poisoning, tricking the client into thinking your IP is the destination. From there the attacker could steal credentials, inject malicious code, or change data.

The tool does incorporate sslstrip, which is a tool that replaces all https:// instances in a website with http://. This would bypass SSL from the client to the attacker, and then relay the data to the destination server via SSL.

Client ->[plaintext]-> MITM ->[SSL]-> Destination

This only works if the original webpage was using http:// and then linked to https:// either via a hyperlink or a form. If the client tries to make a direct connection to the server using SSL (i.e: from bookmark), then you would not be able to force them into plaintext.


What protocols are authenticated by Active Directory? Most of the new authentication solutions (IDaaS) are focused on HTTP (for example implementing SAML and OIDC). What protocols does Active Directory support, that are not normally supported by IDaaS?

It depends which generation of IDaaS you are referring to but in general Active Directory (and other IAM solutions) tend to have better support for on-prem authentication protocols than IDaaS, which is a cloud bridge, does.

I find your question intriguing because I have never tried to compare them previously (they are after all apples and oranges).

I have made a start with a few of the common authentication protocols:

Kerberos = AD
LDAP = AD and IDaaS
NTLM= AD
OIDC = IDaaS
SAML = AD and IDaaS

I am sure others may wish to add to or update this list. If that is the case please comment and I will update the answer.