Usually, you need some sort of escalation.

If you can run the command netcat -v -e '/bin/bash' -l -p 5550 all you've done (effectively) is have the remote machine open a port for you as the user that was running whatever process ran the command. That is to say, if you managed to inject your netcat command into a www process, you are likely logged in as the 'www' user, and not (if the remote machine has been remotely secured) as root.


How does SRP prevent man-in-middle attacks?

SRP is a Password-Authenticated Key Exchange algorithm. One flawed but simple way to see it is that client and server share a secret, on which the algorithm expands; an attacker trying a man-in-the-middle attack does not know the secret, and cannot successfully impersonate either the client or the server (or both, in a true MitM).

What I describe above is "just" using the password as a (pre-shared) key. PAKE algorithms go a bit further, with a lot of mathematics, to be able to tolerate a shared secret of low entropy (namely, the password): an attacker observing the exchange, or even trying to impersonate the client or the server, does not learn anything which would allow him to "try passwords at home" (i.e. he does not get out of the algorithm a hash of the password), something called an offline dictionary attack. This is done with a subtle dance with a classical key exchange and a commitment.

Simplest to understand is Encrypted Key Exchange in which the exchange is a normal Diffie-Hellman, but client and server both "encrypt" what they send with the password. The "encryption" algorithm must be such that decrypting with the wrong password still yields something which looks like a normal DH message (another element of the group). An attacker who wants to run an offline dictionary attack will want to "retarget" a given exchange, by doing something which amounts to "let's imagine that for this past exchange, I had used password P". With EKE, any "retarget" with another password than the one he indeed used leaves the attacker outside of the DH key exchange, preventing him from obtaining the DH session key and testing his password hypothesis.

(I said "simplest to understand", not "simple". It takes some time to cryptographers to wrap their mind around what really happens in PAKE algorithms, which a friend of mine had once described as "a small miracle".)

Anyway, a PAKE algorithm is a key exchange and results in a shared key K. It is still up to client and server to use K to encrypt and protect subsequent data packets, using the usual paraphernalia of symmetric encryption and MAC. This is why SRP is best used as part of SSL/TLS, the latter providing the mechanisms for tunneling long streams of data.


Does SAML 2.0 define how to pass only username from SP to IDP?

Yes, the SP can send a user id to the Idp as part of the AuthnRequest by including a <saml:Subject> element.


City Government Emailing User Name and Password

Yes this is correct. Security principles dictate that you should be able to set your own password.


Is it really "Time to add a word" if there are no tools to crack passphrases of 3 words and up?

You cannot know what tools exist. Actually, if the attack pattern can be enunciated ("just use three random words from a list of common words") then it can be translated to code in a matter of minutes. That the already-compiled, ready-to-run tool is not accessible from a single Google search and a couple of clicks does not mean that it does not exist, only that the level-zero, pre-schooler attackers may have some trouble trying to crack your password. But would you consider your security goal achieved when you have defeated bored kids ?

Any assertion comparing computing abilities with that of "the NSA" should be dismissed as meaningless. You cannot use as the basis of a measure scale a quantity which is already unknown; it would be like describing your new truck as "longer than Nessie". A sentence like:

  Today criminal gangs probably have access to more computing power then the NSA

really reads like:

  I don't know what "criminal gangs" and "the NSA" can do or not, but I want you to get afraid and be crushed by the weight of your own fantasies at that point.

What matters is entropy: a mathematical, precise notion of what the attacker does not know. You should use a password generating process which allows you to not only achieve high entropy, but also lets you compute that entropy with the least possible assumptions; in particular, you don't want to have to suppose that some tools "are not available to the attacker", because that cannot be readily quantified. As for multi-word passphrases, see this answer for entropy calculations.


Installed new Wildcard certificates on my server, but still appear as expired on browser

I found out that I had also node.js instance running on the server.

That node HTTPS server was also using the certificates but since I was only restarting Apache, the new certificates where not taken into account.

Only after a reboot I noticed that there was that node.js server and found where to configure it properly to use the new certificates.

There was no cache whatsoever to worry about.


How to use clipboard manager software more securely?

If you are only concerned with securing the program's files, then you could use TrueCrypt to create a container, mount it as a new drive letter and the install your clipboard manager there. This way, if someone steals your computer, he would not have access to these files.
Full disk encryption is of course a much better option, because it would protect all the files on your hard disk, in case of hardware theft.

On the other side, securing a program you know nothing about is quite complicated. It is not enough to block the program from using the network. Any other program running on your system may access the clipboard manager's files and send them over the network. So be carefull when installing software from unkown sources.

Besides the general recommendations of keeping your system and your antivirus/antispyware/firewall programas updated I would advise using a simple Clipboard Manager, which offers only the functionality you need. If it is simple it means that less things could go wrong.
Moreover, popular opensource clipboard managers are less likely to contain malicious code, as everyone could detect it by analyzing the sources.


With a known secret key, can I determine the response for an authentication challenge?

I have no idea which authentication scheme you refer too. But usually a challenge-response authentication scheme is used to prove that the client knows a specific secret. So the information about the secret are not contained in the challenge (which is often random) but instead in the response. But the exact details depend on the authentication scheme so you need to provide more details if you want to have a better answer.


Trust a possibly compromised system for iso downloads

Get a trusted computer, download the ISO on there and use that as installation disk.


Is it possible to prevent VirtualBox (or other VM) from leaving traces on host?

The mere presence of a VDI (or vmdk) file is an evidence that the host contains a VM. Worse, depending on the configuration of the network, you may have special drivers that clearly state that you do use virtualization on this host.

I can only imagine 2 ways for hiding that:

the standard one is to have a simple normal VM and a hidden Operating System partition in that VM. You show that you use VirtualBox but hide what you do with it...
alternatively, you can use a portable installation on a removable media. When the removable media is not connected, you can pretend that you had used VirtualBox, but no longer use it.

Windows logging system is a pretty good tool, and virtualization may require special network drivers.So except if you know it well and carefully analyze all possible traces, I would not rely on the possibility of hiding any traces but more on just pretending the data you want is not there.


I advise against exposing internal servers directly to the Internet.

Remote code execution vulnerabilities crop up too frequently for comfort and direct exposure of internal hosts.

That said you can mitigate the risks somewhat with a few steps (these are not alternatives, they are layered complementary defenses):

Perimeter firewall enforcing white list of source IPs specifically to tcp/3389 on the Windows host or hosts
Windows firewall on each of the Windows hosts enforcing white list of source IPs specifically to tcp/3389 on localhost
Either: use Remote Desktop Gateways as bastion hosts in your DMZ that are on a separate domain and put the similar restriction to 1 and 2 between DMZ and internal
OR: use SSH bastion hosts and port forwarding as above if RDG isn't a good option

These steps substantially reduce the exposure to reconnaissance or attack


How to generate a batch file with msfvenom?

A .ps1 file is a PowerShell script: unlike .bat and .cmd it's executed in Windows PowerShell instead of the Windows cmd.exe. While it's possible to "convert" a PowerShell script into a batch script that calls PowerShell, the requirement for the PowerShell framework remains.
If that's what you are looking for, for a longer script like the one produced by msfvenom, I'd suggest the method explained in Dmitry Sotnikov's PowerShell script in a .bat file:

Put the code inside curly brackets and assign it to a variable.
$code = {
    # code here
}

Base64 encode it with PowerShell:
[convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($code))

Use it in your batch script with powershell.exe -EncodedCommand


For example this site doesn't have any port specified in its URL so does that mean the stack exchange web server has port 80 open?

Yes. If you dont specify a port for the HTTP protocol, port 80 is used. Port 443 is used for SSL.

  Is it seen as a potential security problem because now an attack can be directed at port 80?

Security always comes with tradeoffs. If port 80 weren't open, none of us could see the website. A store with nothing in the register can't be robbed of cash, but it can't make change for purchases either.

Open ports are usually only considered a problem when they're unintentional, unnecessary, or a result of many unsegregated services on one host were a compromise of one service exposing the backend of another service is a risk.

To answer the title line of your question: Closing port 80 is a problem when you want to run a web service unless you're willing to use a non-standard port. In that case, links will need to be re-written if they're not relative links. Absolute links will have to include a non-standard port number.


What is this address I received from wireshark?

They are MAC addresses. These are Layer 2 addresses while IP is Layer 3. It shows MAC because IP is not known/used in this message.


XSS is not an attack on your application; it is an attack on your application's users.   As a rule, there is no specific threat to the server itself from XSS.

As you have a fairly simple application, you don't suffer from some of the more prominent issues XSS generally creates, like stealing authentication tokens and executing site functionality maliciously, however, that doesn't mean that you aren't at risk at all.

The biggest remaining threat is that of a watering hole attack.   That is, your site can now be used as a vector to attack users who trust it.   If your site is susceptible to reflective XSS, then an attacker can craft links that are legitimately for your site, that your users will trust, but when they use them to access your site, the XSS will inject malware into their systems.

This isn't as much of an issue any more, with the introduction of XSS protection in major browsers, but I wouldn't rely on this alone to protect your users.   Escape user input that is reflected back in order to prevent XSS in the first place.


After having confirmed a computer is infected by a Botnet.

Using a packet sniffer (like wireshark or tcpdump) you would monitor the traffic between your machine and the internet.  You'll want to restart all your connections so the bot needs to reconnect.  Figure out where its going and you can follow it.


A managed switch configured to use VLANs is the proper way to do this. In principle the security you get from the isolation implemented on the router and the isolation implemented by a managed switch is the same.

Of course security vulnerabilities can exist in the products you choose to use. So in practice there can be differences in security between the two approaches. But those differences will be due to security bugs and not inherent issues associated with either approach.

There is a good chance the isolation implemented by the router is in fact done by a VLAN capable switch chip in the router. This answer has a nice diagram of what the internals of typical consumer routers look like.

Some managed switches have a VLAN mode specifically intended for the usage case you describe. See for example this question about VLAN on TP-Link switches.

But even if the switch doesn't have this feature you can expect every decent managed switch to support tagged VLANs which can be configured to achieve the same effect. One potential obstacle to look out for is whether your router supports the configuration of VLANs to achieve the desired isolation. That is something you can verify before purchasing a managed switch.


Beside GIFAR are there any other known polyglot files?

There are lots of examples for such polyglots, i.e. documents which are several file formats at the same time.

Some examples apart from GIFAR are combining GIF and Javascript or Flash and JavaScript but there are lots and even more variants.
A very good source for such stuff is Corcami and also the PoC||GTFO documents are known to be multiple kinds of documents at the same time, i.e. ZIP, PDF etc.


Revoke and regeneration in FIDO U2F / FIDO UAF

Yes, you have to revoke with each service. One of the design elements of U2F is that a site X cannot in any way test or reveal if site Y is registred on the U2F device. Also, its even designed so if someone has 2 accounts on site X, the site X cannot detect that those 2 accounts are stored on the same U2F device.
This to ensure the users privacy so multiple sites cannot track the same user across different sites.

Having a revocation scheme would reveal this fact to the site.

Theres no standarized way of revocation and regeneration, but each site has to implement its own scheme based on security requirements. One scheme can be that using only your username/password, you can revoke your U2F device. To then tie a new U2F device to your account, one scheme could be a physical letter with a one-time code, Another scheme could be SMS in combination with a email. There also possible to issue a revocation certificate.
Or even 2 U2F devices could be tied to the same account at signup, where usage of the second U2F device would disable the first, and then you have to order a third one (that then needs to be activated with the service in question and this third becomes the backup key for the now activated second one).


Generally, no. At least not without preconditions (some of which @tim has lined out), because:

You can only escape from an attribute value by introducing the matching quote. (I assume you're referring to a double-quoted attribute, so a payload without " doesn't get you beyond the attribute value. Obviously, you could escape from a single-quoted attribute because ' isn't blacklisted, or from an unquoted one by using a space.)
In the data state (outside of any tags) you can only achieve XSS by introducing new tags. Everything else is just treated as data. So if < is blacklisted, you're out of luck.


Can recovery of decrypted text possible with memory dump with root privilege in Linux?

This question is missing the implementation context - i.e., the software that implements the algorithm in question. With that caveat, the answers are YES and YES. Intruder with root priveleges can extract both plaintext messages as well as the key.

Recent implementations are a super conscious of this - and try to wipe the key from memory ASAP (interpretations of this "ASAP" vary). It is however practically impossible to bring down the exposure to zero for both the message and the key.

At best, the key can be protected in a hardware assisted solution (SGX or a HSM) - or even a separate decryption solution (not as implied by you - decryption on the same system/kernel.

The message itself cannot be protected as long as it is required for use in that system. Some obscurity can be managed though. e.g., some software use techniques that beat a simple "strings" analysis. I wish I stored the reference somewhere. Unable to link it here.


What attacks does IPSec protect against?

In short, Internet Protocol security (IPSec) is a framework of open standards for helping to ensure private, secure communications over Internet Protocol (IP) networks through the use of cryptographic security services. It is  integrated at the Internet layer (layer 3), it provides security for almost all protocols in the TCP/IP suite (through different policies) and it can help against:

Network-based attacks from untrusted computers, attacks that can result in    the denial-of-service of applications, services, or the network
Data corruption
Data theft
User-credential theft
Administrative control of servers, other computers, and the network
Block untrusted communications

Most of these threats occur throught some sort of Man in The Middle attack. Even if an attack like that is successful, using IPSec will keep the data encrypted and make sure they all reached their destination without any alterations on their way.


Security devices other than firewall and IDS

There are few other choices.  If software is inherently insecure, all you can do is to replace it with something that isn't; or wrap it up in a condom of some sort.  Host-based systems require programs to be invasively, and cooperatively, installed on every client (virus scanners, local network stack IPS).  Network-based systems don't require cooperation from the clients, and try to fix security by parsing traffic.  Some network-based systems require a little bit of cooperation by blocking encrypted traffic for connections that don't submit to scrutiny; and accept the company/ISP's certificate authority (so that the authority at the local boundary can inspect the traffic).


Aren't permanantly logged in accounts inherently insecure?

The trick is too make the "eventually" go beyond the predicted lifetime of the Universe. That's pretty easy because of exponentials: just use a long-enough cookie. Each added bit doubles the number of possible cookie values.

For instance, assume that you have 16 billion users (i.e. each human being, including babies, creates two or three accounts). That's about 234 accounts. Use 160-bit cookies (20 bytes, nothing to sweat over for a cookie). That's 2160 possible cookie values, so only one cookie value in every 2126 is linked to an existing account. Now, our attacker is really motivated and will try one billion values per second (that's really big because "trying a cookie value" means connecting to your server, so we assume that your server is sufficiently kick-ass to handle one billion connections per second -- presumably you could afford that, if the whole of Mankind is your customer). One billion is about 230, so the attacker will, on average, need to try for about 296 seconds before hitting a valid cookie value. "296 seconds" is an amount of time also known as "about 2500 billion billion years": that attacker is surely patient and dedicated.

So this is not a problem in practice: a few more bytes and attackers are thwarted by sheer numbers. There is no need to implement lockout features (especially since lockout features can sometimes backfire by hitting honest customers afflicted with any kind of browser bug that you were not aware of, or something bad like that). Of course this assumes that the cookie values are generated with a strong enough Random Number Generator; think CryptGenRandom() on Windows, /dev/urandom on Linux/*BSD/Solaris, java.security.SecureRandom with Java.

(The bit about the lifetime of the Universe is true only if the Big Crunch hypothesis holds true and there is no God [because eternity is kind of long, too]).


Best reasonable way to store a secret safely

I'm assuming that your threat model is an attacker gaining access to read files on your webserver via some type of web exploit. If not, you should question what exactly you are mitigating with your proposed encryption strategy.

If it is, an option similar to 2 is probably the most simple.

I would use AES128-CBC as the algorithm for a Key Encrypting Key. With a CSPRNG generated 128 bit encryption key, there is no need to use a key stretching algorithm. Algorithms such as PBKDF2 are only needed when you are attempting to secure weak, user supplied passwords. If you can set the keys yourself, you can simply make sure that they are the required bit strength.

AES256 is slower, and with no additional security over AES128.

Make sure your configuration file and your key file is locked down by access control lists.

Key file:

<128 bit random key>

Can only be read by a custom service account.

Config file:

Passwords to systems, encrypted by the key in the Key file.

Can only be read by the web server identity.

Make sure these files aren't servable by your web server (e.g. example.com/config.txt won't work). The way this should work is that you have a service account that runs a process. The web service calls this process and asks the service to decrypt a configuration file password for it. The service validates that only the web server process can call it.

This will protect your secrets from any LFI exploits in your system or server because an attacker in the context of the web server user won't have permission to read the key file or decrypt any credentials in your config file.

It won't protect against physical access, logical access to the system by another administrator level account, or any vulnerabilities that allow a process to be called. It would basically only protect against file reads of the config file directly by the web identity (the user the website itself runs as). If this is not a concern, then there is no need to encrypt secrets at all - the only thing it would really be protecting was casual observation by parties that may see the configuration file.


What does this "ICAgICAg…" mean in public key certificates and messages?

ICAg represents three spaces when text is base64-encoded.

For example:

echo -n '      hello world' | openssl base64

produces:

ICAgICAgaGVsbG8gd29ybGQ=


You create an isolated user first (e.g. with no groups on it),and you run another java instance from administrator (via windows service for example), were you push the commands in a queue, and you got a queue of error codes, in e.g. SQL DB.

And in Linux, you can run also Java from root, and make a queue of commands (with files in folder and SQL, and push the commands and receive the results via another queue).

And the Java instance running exe must run from root or administrator, to be able to run another exe with different user, so you dont need to reload java every time. In windows you would need to compile a binary doing this using windows Process, to launch external command via another user. In Linux you can use "su" or "sudo" commands to do it, so you can do:

[root@abcdef ~]# su - test -c "/usr/bin/id"
uid=503(test) gid=503(test) groups=503(test) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

So your java would require access to the SQL with the queue, so this would be the easier way I suppose, I have did this way and I am so far not hacked.

ps. Queue has to be serialized and with timeout for each run.


How to send a post request where it is neccesary to be logged in?

Postman for Chrome should be able to do what you need. Otherwise a simple solution is to just issue the post request through the Chrome console while you're already logged in.


Is the most recent version of ojdbc7 still vulnerable to CVE-2016-3506?

I don't know the answer, but my guess is that they've updated the driver in the code that they ship with their products, but not in the downloads.  If you have Oracle support I suggest you contact them about getting an up-to-date driver.


Do I need to use salt with api key hashing?

No. You do not need to add a salt to an API key's hash.

The API key should have been created from a high entropy random source, capable of resisting attacks that attempt to guess future keys based on past keys.

Most passwords are created from very low entropy sources: Users.  Additionally, most passwords will also be reused, so there's value in pre-computing hashes for the most common passwords.

The largest easily available brute-force rainbow tables are MD5, alphanumeric, up to 9 characters long tables, which assuming that means Arabic numerals and the upper and lower case US-English alphabet, without accents, then we have 58^9 possibilities.  I don't expect to see rainbow tables longer than 10 characters for any hashing algorithm, so as long as your API key is more than 60 bits (58^10 ~= 430 quadrillion, which is less than (2^61)-1 ~= 576 quadrillion), you're probably safe from rainbow tables.

Use 128 bits to be sure, though.  That way you'll be safe from rainbow tables until the heat death of the universe, even if the person attempting to build such a table has a planet sized computer.

You can still add salt if you want to, though, or if you have a manager with an incomplete understanding of security who assumes that salt must always be used with hashes.  Just be sure that the key itself is still long and was created from a high entropy source.


How can nginx run a file with jpg extension as a php file?

This is not strictly an Nginx problem, but rather is an issue with old versions of PHP.  It has been fixed for quite a long while (I'm not sure exactly what version, but it certainly isn't a concern with PHP 7.0).  The answers to this question:

https://serverfault.com/q/627903/377662

Explain the underlying issue and solution in detail.  The short answer is that what you are calling "virtual directories" are common in many web server applications (including Apache and Nginx) and are used so that the website can show nice urls (aka /categories/5) instead of (categories.php?id=5).  Imagine this flow:

User: Server, please give me /categories/5
Server (to itself): Hmm... /categories/5 isn't a file
Server (to itself): That's okay, this rule says that categories.php knows what to do
Server: PHP, The user requested /categories/5, and categories.php should be able to handle that.  Can you tell me what to return?
PHP: Okay, I talked to categories.php and here is your answer!
Server: User, here is the contents of /categories/5

Which is generally a fairly straightforward exchange.  The server has done everything properly - PHP needs to know not just the name of the file to execute, but also the details about what URL was originally requested.

Unfortunately older versions of PHP used to get confused and, despite being told by the server that categories.php was the thing to execute, would sometimes attempt to "fix" the information coming from the server and may end up executing a different file than what the server actually suggested.  This would lead to PHP executing test.jpg on the basis of the fact that the original URL was test.jpg/whatever.php, even though the server told it to execute a completely different file.

This should no longer be a relevant issue at all.  If you are worried though, you can just set the fix_pathinfo directive to 0 in your php.ini file.  Again, full details and background are explained extensively in the answers to this question.


How is PKI used to encrypt an e-mail for multiple recipients?

This is done as you say, except with an optimization. The email itself is encrypted with a newly generated random symmetric key; and that key is then encrypted with the public key of each recipient. This means that if you have a 2MB email and send it to 20 people, total size is a bit more than 2MB, not 40MB.


Blacklisting of a block of IP addresses - Why?

It's probably because of a couple of reasons:

The IP block was earlier assigned to someone who used it to spam or spread malware.
The IP Block belongs to a country that the site/company doesn't want connections from - generally done for countries that have a very high quantity of malicious traffic originating from them.


How is the TLS version selected between client and server?

Seems that your application (client side) does not accept version negotiation fallback during the SSL/TLS session establishment.

The TLS version is negotiated initially by the client (Client Hello message) specifing the highest version that it supports among other parameters (cipher parameters, etc.). Text from RFC 5246, TLS v1.2:

  client_version:
        The version of the TLS protocol by which the client wishes to
        communicate during this session.  This SHOULD be the latest
        (highest valued) version supported by the client.  For this
        version of the specification, the version will be 3.3 (see
        Appendix E for details about backward compatibility).

After the server receives the Client Hello it sends the Server Hello with the chosen SSL/TLS version among other chosen parameters based on the Client Hello information. Text from RFC 5246, TLS v1.2:

  server_version:
        This field will contain the lower of that suggested by the client
        in the client hello and the highest supported by the server.  For
        this version of the specification, the version is 3.3.  (See
        Appendix E for details about backward compatibility.)

A summary of all this is shown in the following diagram:

I would say the problem is that your Client application does not accept TLS version downgrade fallback during the negotiation and that's why it works when disabling TLSv1.1 and TLSv1.2. Check the bold text in the again RFC 5246, Appendix E:

  A TLS 1.2 client who wishes to negotiate with such older servers will
  send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
  ClientHello.client_version.  If the server does not support this
  version, it will respond with a ServerHello containing an older
  version number.  If the client agrees to use this version, the
  negotiation will proceed as appropriate for the negotiated protocol.

  If the version chosen by the server is not supported by the client
  (or not acceptable), the client MUST send a "protocol_version" alert
  message and close the connection.

An easy approach to debug this, could be to check the logs of both server and application (you did not specify which applications you're using) in verbose mode so you can see the negotation messages. Other more advanced may be to put wirehark/tcpdump to check the negotation parameters. This should be feasible without too much hassle since these information does not travel encrypted.


DC server integrated with DNS trying to contact Blacklisted DNS hostname

If the LDAP server is actually an Active Directory Domain Controller, then it will have a bundled DNS server installed. By default, recursive resolution is also enabled.

Many Windows admins also set this DNS server as the default on clients as it is the easiest way for the domain DNS names to be picked up without delegation.

You're probably seeing that DNS server resolving the domain for one of the clients.

While the DNS server can be configured to log each resolution, it is not very efficient. So the best way to find out which clients are involved is to look for connections to the IP that is returned by DNS.


RSA-1024 vs. DSA-1024: Claim DSA SSH key is much faster to brute force

Trying to brute force either a RSA or DSA key would be a losing proposition, there are far too many possibilities and there are far better attacks known.

For properly implemented RSA the best-known attack is factoring the modulus. For properly implemented DSA the best-known attack is solving the discrete log problem.

For a given key size the discrete log problem is believed to be somewhat harder than the factoring problem.

However DSA has a couple of practical problems.

DSA keys were conventionally limited to 1024 bit which is considered dangerously low nowadays.
Traditional DSA implementations are very sensitive to random number generator quality. Making signatures with a broken random number generator can compromise the key.


The main information I get from your question is that you don't know what kind of threats to expect in your network, but nevertheless you hope to address them using some kind of IDS. This will probably fail.

So the first thing would be to make a risk analysis, develop a threat model and then do a cost/benefit analysis to decide which threats should addressed and with which risks you can live. And because the threat landscape is moving you should reevaluate your decisions often enough.

Just an example: If you fear an attacker coming from the outside you could deploy a passive central IDS to detect intrusions. Unfortunately this will not prevent intrusions so they will probably spread through your network and can only be detected with IDS which near the host. Host-based IDS itself might also work unless the attacker is able to disable them once they owned the system. Instead of using passive IDS you might use active components which not only try to detect but also to prevent attacks. You find them usually named as firewalls,IPS, NGFW, UTM, Secure Gateway... . But be aware that none of these will detect and prevent everything, and usually they detect much less than their marketing claims.

And of course you should now on which level you expect the attacks: a simple packet filter will not detect application level attacks and how good something like drive-by-downloads or waterholing attacks with 0-day exploits get detected depends a lot on the capabilities of the IDS/IPS and also a lot on your ability to tune it specific to your environment.

So just don't expect just to put something there and be safe - you probably have to invest lots of money into technologies, but also a lot of knowledge and man-power to maintain the system and keep up with the latest threats.

In summary: there is no clear answer to your problem. Only after you have made an in-depth risk analysis you can decide what the best way would be with the amount of money, man-power and knowledge in your budget.


Doubling up or cycling encryption algorithms

Cascading or cycling encryption algorithms increases implementation complexity, and that's really bad for security. Algorithm intrinsic security (provided that you use published, well-analyzed algorithms, not homemade designs) is invariably far greater than implementation security: most implementations may leak various elements, including secret key bits, through execution timing, cache memory access or insufficiently strict behavior when encountering incorrect data.

If you have covered all the implementation hazards, then it becomes time to worry about the algorithms themselves; at that point, you are a trained cryptographer and you know better than relying on irrational tricks such as cascading or doubling. Basically, the one thing that algorithm doubling or cycling guarantees is that whoever makes the suggestion is not overly competent in the area of cryptographic implementation, and therefore you do not want to use his code.

Historically, cascading or cycling are ways to cope with weak encryption algorithms; this is about assuming that any algorithm will be broken, and you try to do damage control. This somehow negates all research on cryptography since the 70s'. In practice, security issues are in how an algorithm is used (e.g. chaining mode with block ciphers), how an algorithm is implemented, and, most importantly, how keys are managed (creation, storage, destruction...). In order to have the algorithm itself be a weak point, you have to make huge efforts (e.g. designing your own algorithm, as the DVD consortium did). As an example, when modern game consoles are hacked, the algorithm themselves (AES, ECDSA...) are not broken, but circumvented (for ECDSA and Sony/PS3, this was a downright implementation bug).

What you do want is to have algorithm agility: you define the protocol such that the used algorithm is a configurable parameter. Therefore, if a given algorithm turns out to be flaky (which does not happen often at all), then you can switch to another.


Important data can be modified from the developer console. What should I do?

Most of the details in your question are irrelevant. That the ID is stored in a HTML id attribute, the developer tools, that you are using jQuery... None of that really matters.

The only thing that matters is that you have an endpoint on your server called insert.php. An attacker can send any request they want to that endpoint, regardless of what your client code looks like. Protections against people trying to do things that they are not allowed to do must be at the server, and not the client.

So look at your PHP code. Does it verify that the input is in the expected format? Does it check that the user has the right to edit the particular todo list? If not, fix it. And remember, your validation and authorization checks must be performed on the server to have any security value.

Specifically, if users should only be allowed to edit todos that they own you need to do the following in insert.php:

Query the database to get the owner of the todo that is being modified.
Get the id for the user making the request.
Check that they are the same, and deny if they are not.


How likely is to have a hash function output flip a bit?

It is very unlikely that the bit flip happens during hashing - which is a very short time and there are only comparably few instructions involved compared to the preceding processing of the input. It is instead much more likely that any bit flips already happened before, i.e that the hashing is already done on corrupted input.


Privacy concerns with the iOS Freedom app

Yes, of course they could be. If they are to believed (which I do), they are just using a 'local VPN' which is pretty common in ad blocking apps on iOS. These apps have the full capability to tunnel your data off to wherever and you'd be none the wiser. They use the iOS VPN extension system so they can decide if they want to block or drop a connection. The VPNs, unless you install a certificate, cannot decrypt your SSL traffic because it is encrypted before it reaches the VPN interface.


How to prevent (cookieless) csrf attack?

So this is a REST-ful API that you're working with and your clients are using browsers that don't support cookies, ergo authentication to your API is done via an Authorization header? And I take it that the contents of this Authorization header are populated per the contents of the response from the login API endpoint?

If this is the case, your API is already protected against CSRF. CSRF against the login endpoint would only work if the response from the server set a cookie within the victim's browser which was then used to authenticate subsequent requests.


Does HSTS make using a public WiFi safe?

Short answer:

Yes, for resonable defintions of safe.

HSTS protects you against sslstrip type attacks for sites you have visited recently using a non-compromised connection (or for some browsers sites that are stored in a hardcoded "preload list").

The regular SSL CA system protects you against MITM attacks of ssl connections where the attacker has not compromised the CA system.

HKP (which is often used in conjuction with HSTS) provides you with a large degree of protection against compromises of the public CA system for sites you have visited before (or for some browsers sites that are stored in a hardcoded "preload list"). Exactly how much depends on what keys the site operator decides to pin, if they pin an intermediate cert rather than the server certs then the entity controlling that intermediate cert can MITM you.

HKP does not protect against MITM attacks by roots you manually added to the trust store. This was a deliberate design desicion to allow corporate SSL inspection systems to keep working.

No SSL based system protects you from MITM attacks if the attackers have managed to compromised the legitimate server's private key.

And of course there is always the risk of bugs in the protocol design or implementation or weaknesses in the underlying cryptography.

I covered a load of scenarios more explicitly in my (rather long) post at https://security.stackexchange.com/a/110004/79347


What should be Database encryption strategy ?

Yes, else the attacker could grab the key off the wire as it passes to the client and can decrypt the information the same as the client. One needs to use a secure key exchange, the easiest way to do that is to push everything through SSL.


Will I jeopardize security if I store the first three characters (hashed) in a separate table?

If an attacker gets access to the stored hashes and knows that each of these only encodes a single character he can brute-force this character with very few guesses. The salt does not protect against this since it is part of the stored password hash and thus known to the attacker. The slow-down done by bcrypt does not help either since only a few characters are to guess.

Even worse, once the attacker got access to the first 3 characters of the password this easy way brute-forcing the remaining characters is considerably less effort as if the password would need to be brute-forced in full.

If there is no separate hash for each of the first 3 characters but only one hash over all three together it is not as insecure as with three one-letter passwords but still totally insecure.

In order to make the problem of storing one or few instead of all characters of a password in a separate hash more clear show the math involved consider the following an example:

Assuming that a password consists of 100 random digits.
When brute-forcing this password at once an attacker would need to check at most all 2^100 permutations and on average the half which is still too much for practical attacks.
But, if all these digits are stored in separate hashes and the attacker thus gets a positive feedback already after cracking the digit for a specific position he only needs at most 10 attempts for each position and thus 10*100 attempts in total. This makes the password trivially to crack within a short time even if each attempt would take a full second. And no salt will protect against this.
If you don't hash a single digit but only combinations of 3 digits it gets a little bit better but is still far from secure. In this case each of these hashes for 3 digits would need at most 1000 tries. With 33 of such hashes (and one for a single digit)  o store the original 100 digit password an attacker would need at most 33*1000+10 attempts, i.e. it is still absurdly insecure.


Possible to detect and log CORS and preflight requests in IIS?

Well, there are two types of cross sites requests.  One would be from your web pages to a separate domain and the other would be from outside domain web pages to your website.

Let's say that you are serving a web page from iis with a malicious image or script.  When the user makes the request for that page iis can log all the http requests (images, scripts, html, etc) to it's own server but not to the malicious server.  So you won't see any http requests in your iis logs.  Capturing of http requests that happen from your web pages can only be done at the client level.  Unfortunately, javascript does not have an api for capturing http request events but tools such as fiddler or firebug can show you all the http requests that are sent when a web page is loaded.  For this scenario you may be able to achieve your desired results by scripting a crawl of your website and enumerating all the http requests that are made.  You would then check if the domain of the request is your own and what the http response code is (success vs. failure).

The other scenario is if malicious data is being hosted and served from your website (e.g. someone uploaded some javascript and is calling it from another website).  A simple way to detect this is to parse your iis logs looking for http requests to non-html file types with a referrer other than your own.  The referrer can be spoofed if the attacker has enough foresight to do so.  This can also be actively prevented via a http module, url rewrite rule or via your website code if you set up something to serve your files.


Some public CAs have multiple roots, and more use multiple roots.

Assuming gmail means mail.google.com, as the (currently two) reports at SSLLabs show google uses its own intermediate CA, (CN) Google Internet Authority G2 issued under (CN) GeoTrust Global CA.

That Geotrust CA has a root cert with (SHA1) fingerprint beginning DE28, but also a nonroot bridge cert (included in server handshake) with fingerprint beginning 7359
under (OU) Equifax Secure Certificate Authority; that Equifax CA in turn has a root cert with fingerprint beginning D232 which was issued in 1998 so it was pretty well established and trusted when GeoTrust started in 2002 and initially was not trusted. Today the bridge cert shouldn't be needed, and pretty soon it will actually hurt because its chain expires sooner.

For more on Geotrust (and Google) anchoring, see:

google certificates correct CA
Different SSL cert behavior with Chrome on desktop vs. Chrome on iOS
What happens when certificates further up the chain expires before mine? (Equifax/GeoTrust)
https://serverfault.com/questions/589590/understanding-the-output-of-openssl-s-client

@Steffen's answer points to a comparable but slightly different case, multiple generations within Verisign.

UPDATE 2017: The Equifax root cert, and thus the GeoTrust bridge cert, are no longer valid using the MozillaNSS-also-curl truststore, see https://serverfault.com/a/841071/216633 .


How is security risk of storing authentication token in localStorage compared with cookies?

A cookie marked httpOnly, as the name implies, cannot be accessed from javascript.  So a 'conventional' web application using cookies is not vulnerable to naive XSS attacks if that flag is set (assuming no browser bugs expose it of course.)  Notably such a solution is vulnerable to CSRF, so more work is required to mitigate that.

In SPA frameworks you generally need access to the cookie in javascript anyway because they want to put it in an authorization header, not simply rely on "old school" cookie based security.  This has the advantage of now being CSRF resistant.

The basic rationale for an SPA is if someone manages to inject javascript they have won.  You must not have XSS vulnerabilities because the attacker can alter anything about your entire application and simply do inside the victim's own browser whatever malicious thing they would have done with the stolen token.  (or simply alter your app to steal the user's plaintext password...)

Therefore people choose to tolerate the potential exposure of the session token, because the assumed consequence of a successful XSS on an SPA is 100% compromise anyway.

(In my opinion this is by no means a settled topic, people are still having nasty arguments about it.  There's endless blog posts and forum flame wars advocating on both sides.)


So, I don't know why they did this, but knowing developers and their attitude towards third party software here's my speculation:

Developers tend not care about the whole system, they want to know about the bugs in the code they wrote.
Scanning third party code takes time.  Why take time to discover things that the average developer doesn't care about?

Should developers care about the total product's security?  Of course.  But the typical developer isn't evaluated on that, (s)he is evaluated on the code they produce.


Cookie without secure flag but with httponly

You should still set the secure flag, even if your site is only served over HTTPS. A single unencrypted HTTP call is all it takes to leak a cookie, and it can even be to an endpoint that doesn't exist or isn't served over plain HTTP. The only way to prevent all such calls is to use HSTS with preloading. And even then, setting the secure flag costs you nothing, so why not do it?

As for the HttpOnly flag, it is for protecting cookies in case of an XSS vulnerability. It is completely unrelated to the secure flag or any other issues related to HTTPS. It does not protect you against MITM attacks, which is what the secure flag is meant to protect you from.


How do I get back to a Meterpreter shell after backgrounding it?

Regarding the original question, I found the answer to how to restore the backgrounded session. I have to use channel -i <channel id> to get back to the specific backgrounded session.


Storing database password in application

This actually sounds like a pretty decent use case for PostgreSQL's TLS support.  You can configure a trusted client certificate for the application to use with your deployment script and then get the other advantages of not having a shared secret, plus obviously encryption too (unless your app is already CPU bound, in which case selecting the NULL cipher is a possible workaround).  Sometimes adding TLS complicates matters, but it sounds like in this case it might actually simplify them.

http://www.postgresql.org/docs/9.1/static/ssl-tcp.html

TLS session bring-up can add a few milliseconds of latency, but if you're already managing a connection pool, I don't suspect the app would notice.


Could an attacker connect to a SSTP VPN if they know a users credentials but do not have the public certificate?

Yes. An attacker can configure VPN client to ignore certificate errors and successfully connect to VPN. Server certificate validation occurs on client and server has no idea how client validates it.


Is using VPN on a router more secure than using a dedicated VPN machine?

It depends; there are about three things you must consider:

Does the software provided meet your needs (security and performance)?

Since you're using OpenVPN Server on ESXi, you'd probably be fine using OpenVPN Server on a pfSense firewall.  IPSec VPN on that same pfSense box would also probably work for you, if you know how to configure it correctly.
The specific consumer router you listed appears to have PPTP VPN, which may or may not meet your needs.

Does the software contain known vulnerabilities as first obtained (installed or bought)?

This is always a "check current news" item.
So, you must ask - where can you find such news for a given product, i.e. how would you know?

Forums?
Contact the maker?
CERT?

When a vulnerability is found in the future, how will it be addressed?

Some vulnerability will be found, at some point in the future.  Such is the way of code written by humans.
Look at past performance: how well has a given maker addressed the recent big bugs, like Heartbleed and Shellshock, etc.?

On their current products?
On their older products?  Look for a product about as old as you hope to keep this one; see how they handle updates and patches.

My gut instinct is that serious firewalls will be quite good at handling all of these with their built-in VPN's, if they either have free maintenance or you buy the support plan, and the consumer grade stuff will not be kept up to date.

As far as port forwarding to the local network, you are correct; my pfSense installation simply asks which interface (WAN, in your case) to open the specific OpenVPN server port on.  However, I'd be hard pressed to see opening a single port for UDP only (or TCP only), to a single internal address which runs OpenVPN as a significant security flaw; this is, after all, what you use a firewall for.


SQL Injection and JavaScript Regex Bypass

Disable your javascript.

If your using FireFox:
Go to "about:config" then "javascript.enabled" set to "false"

If you just need to remove certain javascript as you rely on the other javascript install FireBug and remove the code you don't want.


For demonstration purposes, I personally would just create a few virtual machines, and demonstrate what you can do to them locally. As mentioned, placing a vulnerable machine on the internet is just a bad idea. If you can hack into it, so can others... and as my firewall logs indicate, there's always someone poking around...


For this situation unless using a hardware encryption module the raw keys have to be available to the machine. For the encryption to offer any real benefit the keys must be stored in a format which is harder to read than the underlying files.

This means either

store the files on a separate machine to the application. If the application server security model is broken they still have access to everything but if the file server is accessed all they get is encrypted information.
Store the keys in a way that they aren't readable to the application. This is usually done by having a process running as a more privileged user read the keys then pass them through to the application on start. This means the only way any attacker gaining access as the same user as the application (assuming no opportunity for privilege escalation) can get hold of the keys is to read them out of memory or a core dump of the application.


.fuse_hiddenXXXX files are explained here on askubuntu.com

You can safely ignore .fuse_hiddenXXXX files. It means a file was deleted but there is at least one software which is still using it, so it can't be removed permanently.
It will be done automatically when the relevant software stops using the file or exists. Such files are always gone after umount/reboot. This is how Linux and any Unix works but only FUSE exposes these files to the user.
These files are also related to the ntfs-3g file system.

You can find out what application has the file open by using the lsof command.
lsof /full/path/name
-OR-
lsof /relative/directory/path/name


Two factor authentication turned on for my Google account (Phone) - but still hacked

There is a malware which is spreading nowadays that clone the ID of chrome, so an attacker can access any site/s thanks to cookie sessions saved on that chrome. The technique is very sophisticated and 2FA it's useless here because they're already logged in with your cloned browser id and nothing require to be checked. So most probably, if you're a google chrome user, you could have been affected by this kind of attack. If this is your case, the solution will be as follow:

  ·LogOut your google account from the infected machine (of course, run
  Malwarebytes or any other kink of anti-malware to delete the virus)

  ·Uninstall google chrome and/or any kind of chromium-based browser(and
  all of its related data)

  ·Now you need to change the name of your computer (so the new session
  will have a different name avoiding name hijacking
  https://kb.iu.edu/d/ajnx)

  ·From a different device change the password of your google account

  ·In 2FA google settings revoke all authorized devices

  ·Reboot your pc and reinstall chrome.

You should be done.


How should I configure my firewall using iptables commands to defend against hacking?

I wonder what corporations and politicians and oil barons do to
protect their devices from targeted hacking?

Ask Jeff Bezos or Angela Merkel, they'll know.
Oh wait ...
It always depends on your adversary. There's a difference between Joe hacker and the NSA.
The average Smartphone usually does not expose any public internet services itself and is often behind some NAT anyways. So theoretically no one from the outside can connect to it directly. Often you "invite" attackers by connecting to their phishing websites, installing some crap app ...
Telemetry/Tracking is also just some kind of legal version of exfiltration.
Preventing exfiltration is nice in theory but in practice only limiting traffic to port 443 and 80 still gives the attacker the ability to exfiltrate data over those ports. Not to mention some lower level stuff like WIFI, Bluetooth, mobile network ...
Smartphones are made to communicate in many ways.
The average politician targeted by the average nation state better does not do any stuff on his phone which could have negative impacts on him. Like storing all his duck pics ...
The true chad politician, however, would store all his duck pics there on purpose because a) remove the attack vector of some moral outrage and b) because the images exploit some vulnerabilities on the attackers system and send all their duck pics to youduck.com
2:0
You'd better prevent or detect the step which happens before exfiltration i.e. compromise. You'd need to know what the system does normally and when it misbehaves. You also need to know if normal=desired (see telemetry ...) That's a lot of work. iptables/firewalling is only a small part of it


Why is it not possible to spoof referer and origin header with XHR?

You can't set those headers, because the browsers ignore attempts to set them. Browsers ignore attempts to set them, because they aren't supposed to be script-controlled. The restriction on letting them be script-controlled is for security reasons. If you could set the Origin header, you could break the security guarantees of CORS. Since the whole point of CORS is to open gaps in the same-origin policy for trusted origins only, letting a script (which can be attacker-controlled) spoof the origin is obviously unsafe.

Another question would be: why should XHR/Fetch allow you to set those headers? What legitimate reason is there to do that? There's a good reason to disallow it (breaks a security guarantee, setting us back to the bad old days of JSONP where you couldn't be sure who sent the request), and no good reason to allow it, so of course it's not allowed.


I recently joined my own school's cyber security club with no security knowledge and learned a lot in the months preceding the CCDC. First thing's first – linux skills are crucial; stopping and starting services, seeing who is logged into the machine, adding/dropping users, general directory structure & location of commonly needed files, familiarity with each distribution's package manager, where log files for different things are & how to read them, common ports, iptables or other basic soft firewalls, etc.
From there we looked at hardening different applications and protocols (ssh, imap, pop, active directory). We often did this by renting virtual private servers for less than a cent per hour (from places like digital ocean), but I would also suggest beefing up your linux skills through wargames like those on overthewire.org or hackthissite.org. We didn't look at networking at all, and only one out of the six teams competing used the provided hard firewall.
I'm not sure there is some go-to book for this type of stuff (there is a red team field manual field manual but no blue team counterpart??!), but there are tons of good resources on the net that will help you. I watched a lot of post-CCDC debriefs on youtube to see how teams tended to get owned and then learned about how to prevent that. Digital Ocean's knowledge base and nixcraft have great guides on how to harden basic things. You can also try googling around for other team's CCDC cheat sheets and research everything you don't recognize. The event organizers should also have some non-specific lists of technologies you may be responsible for during the competition.


Encrypt entire CSV file, but decrypt only specific fields?

Transpose the CSV before encrypting. So each column is its own contiguous block.

So the CSV:

a,b,c
1,2,3
4,5,6
7,8,9

is stored as three blocks. The format of these only requires that you have some way of finding the beginning of each column in the file and that you have some way of delimiting values. I am not specifying an encoding. But one could use CSV encoding for the values where the spaces in the following are actually commas and the values are a single line.

a 1 4 7
b 2 5 8
c 3 6 9

Each of the lines represents a block where the part in brackets is encrypted:

a [1 4 7]
b [2 5 8]
c [3 6 9]

Then you can iterate over the rows by doing decryption steps on each column and merging their output to produce rows as the values may be of variable length the amount of decryption steps on a column depends on the length of the value in that column.


Looking for general guidance on securing web API application for client applications and users

The easiest way is to use an SSL connection, have them provide authentication credentials and then return a session token to be used with future requests for that session.  You can then expire the session token after whatever time amount you want (at which point it would be necessary for them to send another authentication message.)

That's of course assuming that there is no built in session management in WebAPI.  It's a bit before my time so I'm not all that familiar with it.  I mostly ended up using WCF based services where there is a lot done for you in terms of session management.


Could a request sent by a XSS attack in a change password module be cosidered as a CSRF?

I wouldn't classify it as CSRF.

The protection mechanism that is failing here is XSS protection, not CSRF protection; If there would not be an XSS vulnerability, you could not perform a CSRF attack. It is true that all XSS vulnerabilities can be exploited to bypass all CSRF protection that are not challenge-response based (passwords, captchas, etc), but that doesn't mean that all XSS vulnerabilities should be classified as CSRF.

There is also no separate classical CSRF vulnerability here. Even though there is no token protection, the form is protected from CSRF via a challenge-response mechanism as a password is required. Your partner does have a point regarding the bruteforce scenario via CSRF though. I would consider it a vulnerability if there is no bruteforce protection for the form, and I would suggest adding whatever CSRF protection is used in the other modules. I would classify it as a bruteforce vulnerability (via CSRF) though.

Apart from that, the fact that the password is even shown is a vulnerability by itself, as is the fact that the passwords are apparently stored in plaintext; You should first check though that the password is actually given by the application, not by the browser- or a plugin-based password manager.


Is it secure to use jQuery on the server-side for user input validation?

You need to verify that the HTML is valid (e. g. proper nesting of ", ', <, >).  Otherwise different browsers will use different algorithms to "fix" it. This results in them seeing different things as tags.

Furthermore there is a high risk that you add too much to your whitelist. For example, the href attribute may contain active content, such as jaVascript:, vbscRipt:, java scriPt: amongst others.

On Internet Explorer there is an expression() function that can be used in CSS to execute Javascript.

I strong suggest to use one of the existing libraries to sanities user input, such as html purifier.

Please have a good look at the XSS cheat sheet.

Last but not least, keep in mind that an attack might work completely without JavaScript, by injecting a form asking for a username and password.


Hashing a large file on an embedded system

As long as you receive the file in order from beginning to end, you can calculate the hash incrementally. Any cryptography API that's suitable for embedded systems (and most of the ones that aren't) lets you calculate hash by passing successive chunks of the input. Each time you've received a chunk, feed the input to the hash calculation and append it to a file. When the transmission is over, finalize the hash calculation, and erase the file if the hash is incorrect.

Note that a hash can only verify the integrity of a file, not the authenticity. This means that the device needs to know the hash value in advance, so you need to transmit the hash through another channel. This is typically done by using a slow, but trusted channel to transmit the hash (e.g. end-to-end TLS to a trusted server), and a channel with more bandwidth but less security for the file itself (e.g. a broadcast mechanism).

A hash tree is only useful if you need to be able to verify parts of the file independently without having to retrieve the whole file. If you're getting the file sequentially and fully, it isn't useful.


How to circumvent compromised CPUs in major FOSS operating systems

The AES instructions have to produce the proper output. If they were tampered with in a way that changed output, it would be detected very quickly, and there have been no reports of that. This limits the scope of tampering considerably (to side channels and such), and I can't see that being readily exploitable by the NSA.

A random number generator is a different beast. It's possible that while it looks to you and I like a random stream, it has some special property that the NSA can use to predict it. RdRand and Dual_EC_DRBG are both under suspicion.

So a practical step is to use additional random number generator instead of (or in addition to) RdRand. Most crypto libraries already do this, or can be configured to (more info)

That's probably the only reasonable countermeasure. In theory a backdoored CPU can do anything: leak your plaintext directly to the NSA, store your keys permanently on the chip, etc. But there's nothing you can really do about that.


For sure do everything you can to to disable all ways to tunnel traffic between your servers and clients. I like the design above:

http://undeadly.org/cgi?action=article&sid=20100321135641


How long til a 4-way handshake is captured with Aireplay-ng

Usually it takes only few seconds.however, if you're using the card on a virtual machine you might face problems.

I can confirm that the card works (i tried it myself).
first time was with Backtrack-5 live boot CD and it worked perfectly, next time was on virtual Kali 2.0 and it didn't work.
Just as you described it, the deauth packet goes and nothing happens.


Secure authentication cookie for web site

So here's how this works: we tend to consider 128 bits of random data unguessable. See Why so long to break 128-bit encryption? for some talk about that.

What you want to do is calculate the birthday attack. There are some other questions talking about this in What are the chances to generate the same ssh key? and What is the collision chance of a 128-bit hashing function if it is always fed with 256-bits of data?.

Your token there looks like it's Base64 encoded, so it provides 6 bits per character. That's over 3,000 bits of data. Encode something smaller (128 bits raw, 170+ in B64) and save yourself the bandwidth.

For the second part of your question, see How is an HTTPS login secure when pages use HTTP?.


You only give a limited amount of information about the system, so I can only give a broad answer. A good source for orientation is the current ASVS (Version 4.0.1). In chapter "V12: File and Resources Verification Requirements" we can find requirements for file uploads that point us in the right direction. I've selected some of those requirements and added an explanation to apply it to your scenario:

12.1.1 Verify that the application will not accept large files that could fill up storage or cause a denial of service attack.
12.1.2 Verify that compressed files are checked for "zip bombs" - small input files that will decompress into huge files thus
exhausting file storage limits.
12.1.3 Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.

These requirements are mainly about denial of service attacks by flooding the application with files until it runs out of storage capacity. If the target system doesn't protect against such attacks, this might be an important risk to address.

12.2.1 Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.

There are many reasons for that, but in general, you have to check if the file is used in a way, where a wrong file type can cause damage to the system. Without knowing the details of the application, I can only guess if that's the case.

12.3.1 Verify that user-submitted filename metadata is not used directly with system or
framework file and URL API to protect against path traversal.
12.3.2 Verify that user-submitted filename metadata is validated or ignored to prevent
the disclosure, creation, updating or removal of local files (LFI).
12.3.3 Verify that user-submitted filename metadata is validated or ignored to prevent
the disclosure or execution of remote files (RFI), which may also lead to SSRF.
12.3.4 Verify that the application protects against reflective file download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.
12.3.5 Verify that untrusted file metadata is not used directly with system API or
libraries, to protect against OS command injection.

Path traversal means breaking out of the current location and write to other locations. This might enable an attack to write over an existing file or place executable code where it either gets executed by the system or can be executed by the attacker. If that's possible, that can be a severe risk. The other points are going in a similar direction. The basic idea is, if an attacker can manipulate the meta-data in a malicious way, different attacks are possible. Command execution would be one of the most severe risks. If any of those apply to the actual system, must be verified.

12.4.1 Verify that files obtained from untrusted sources are stored outside the web
root, with limited permissions, preferably with strong validation.
12.4.2 Verify that files obtained from untrusted sources are scanned by antivirus
scanners to prevent upload of known malicious content.
12.5.2 Verify that direct requests to uploaded files will never be executed as
HTML/JavaScript content.

Storing the files in the web root may allow an attacker to execute the file directly or simply use the application to serve malicious content to others (e.g. to do drive-by infections, perform XSS against to domain). A malware scanner is able to identify such malicious files, if the pattern is known to be dangerous. If those safety nets are not present in the applications, the attacks described can be a risk.

Those is a broad field of potential attacks. Which of them actually apply to the application you are testing, must be verified. If you have the chance to do the audit white box, you should be able to verify all of those potential risks based on the source code and the server config. If you have to do it black box, some of them might be tricky to verify.


PKCS#10 is a specification defining what and how attributes should be contained in a Certificate Signing Request in order for it to be compliant. It is used as the default specification for most certificate signing authorities. This specification dictates the use of ASN.1.

ASN.1, also known as Abstract Syntax Notation One, is a standard that defines rules and structures for data representation. In this case, it is used to specify how the attributes you put into a PKCS#10 request should be formatted.

OpenSSL X509Req objects are classes that you can define attributes against in order to build a Certificate Signing Request. You build and add attributes to the request object. By using code similar to the following, you can then dump the class into an ASN.1 format.

req = crypto.X509Req()
output = crypto.dump_certificate_request(crypto.FILETYPE_ASN1, req)

If you create such an object, include the attributes and data required by the PKCS#10 specification and then dump it into the ASN.1 format, you have created a PKCS#10 compliant certificate signing request.


Can malware be installed on my mobile considering it has MDM?

Yes:

I don't have experience with Mobile Iron, but I have used other MDM clients like AirWatch.  They do not inherently give more protection or scanning for malware.  MDMs are simply management solutions and remote administration (very limited in some cases) for devices the provider would like to issue resources and connections to.  Some things may help, like requiring a password to install anything, and restricting the app stores - but, unpatched exploits like Quadrooter would still have an impact on you.  Secure AV deployment would aid a bit in security, but as always is not a bulletproof methodology.


What's the value of data partition encryption for database files on a postgres database server?

First off, there are ways to mount encrypted partitions without having to enter the passphrase manually or storing it on the system that is being protected. Look at Mandos for one example of this; it's basically a client/server application that stores the key to unlock the encrypted container separate from the container itself. An attacker would at the very least need to gain access to the content of both systems in order to be able to circumvent the security. An alternative to this might be something like the YubiHSM or even just a low-tech solution of a few thumb drives attached to the key rings of trusted employees. This renders your issue about having to enter the passphrase on boot or storing it on the system itself largely moot.

Second, full-disk (or even just whole-partition) encryption allows for efficient and reasonably reliable destruction of data: with any half-way competent crypto, if you throw away the keys, then the data becomes inaccessible. This can be important if you are decomissioning a hard drive that won't respond normally to host commands. It also means you don't need to worry at all about drive-level relocation of sectors in terms of data remanence (and can likely dismiss that issue entirely).

That said, obviously while the system is running the encrypted file system needs to be fully accessible, so there are many attack vectors that full-disk encryption does not at all protect against. It does, however, add an additional layer of difficulty for someone who wants to attack the data at rest, at potentially marginal cost to the defender. For many situations, especially if you can handle the key management problem, such a trade-off can make sense.


DDoS Mitigation - Whitelist or Blacklist Incoming SOURCE Ports?

In terms of security, it is better to have a whitelist approach rather than a blacklist. As Neil has clearly pointed out, you should only allow ports for incoming connections in your firewall that corresponds to the services that you are providing and need to accessed from the outside.
Hope my answer helps you better understand the situation.


Are bad passwords used to breach security in real life?

Yes, stolen passwords are used in real life attacks. I didn't actually know myself until I searched, and it's buried all the way on the third page of my fourth or fifth Google search; i.e. the information practically doesn't exist. ;-)

Anyway, apparently back in 2012 there was a period of several months where Best Buy accounts were compromised by stolen passwords from another site. And in 2015, Verizon estimated 63% of data breaches used stolen, default, or weak passwords. I don't feel like registering to download the full report from Verizon so I'm not sure how many were stolen vs. weak or default, but I'd guess it's a significant portion if they're reporting it that way.

I'd guess more information is out there for the finding if needed.


Is it possible to respect a user's privacy while collecting phone MAC addresses?

Cryptography is rarely the right tool for privacy issues. Here, the trash bins are listening for the broadcast of MAC addresses by WiFi enabled devices, in particular phones. The tracking part is made possible due to the combination of several parameters:

WiFi-enabled devices broadcast data regularly. This is rather unavoidable: for WiFi to actually occur, either the device or the access point must talk first. Since there are "hidden" access points who do not talk until specifically addressed, the devices must blabber about constantly.
MAC addresses are fixed. An important point of MAC addresses is their uniqueness: things must be so that no two "unaltered" devices may use the same MAC address simultaneously, on the same local network. To ensure this uniqueness, a global allocation scheme has been designed, with hardware vendors being allocated address ranges. It is possible to force a MAC address change on most hardware, but this is "frowned upon".
People don't switch off the WiFi when not at home. They should (in particular, not using WiFi extends battery life), but they do not.

In the example, the trash bins just listen to all the broadcasting, and correlate data between each other, thus "tracking" the whereabouts of phones (and thus, presumably, of phone owners). A lone bin would not get much interesting data, but a lot of bins can come up, together, with a rather thorough map of movement behaviour of people. Note that the MAC address cannot be traced back to an owner identity, but it can, at least, uncover the hardware vendor name, because of the global MAC allocation system, which is public.

What could be done, assuming that we are free to define new protocols, is to replace the fixed 48-bit MAC addresses with random 128-bit addresses (regenerated frequently, e.g. every minute will not actually connected to an access point). Random addresses of 128 bits ensure uniqueness with sufficiently high probability, even if lots of devices are happen to be in the same location. For instance, if you have a stadium full of 60000 people, each with a phone, and they all try to do WiFi, 128-bit random MAC addresses would allow a collision to occur with probability about 2-97, i.e. "won't happen". But here we are talking about defining a new WiFi protocol and hoping for all devices and access points to simply switch to it, forfeiting any attempt at compatibility with existing WiFi access points. This kind of change is unlikely to occur within the next few years.

In the meantime, if you value your privacy, then simply shut down the WiFi !


Is it dangerous to call spam phone numbers, even if you know they're spammers?

Can you get "hacked" by calling a number?

  I am curious if calling the number would do something to my phone. How could a hacker possibly access sensitive information just by tricking someone into calling.

It could be a hack, or it could be a prelude to a hack. Here are some rough examples:

If you call them, the spammer can find out if that phone number is owned by an actual person. The spammer can also easily fake the same area code as you, and set up a clever social engineering trick that may involve you thinking with the wrong head.
If you're dumb enough to call them, you may be gullible enough to fork over additional information. If you're dumb enough, they may call you from other numbers, or forward you to another number.
There may also be an exploit in your phone's processing of various messages/content types. While they could easily target all phones at once by using some form of auto-messaging feature, this may be easily stopped by carriers.

Learning more about you allows an attacker to guess secret answers, passwords, etc. If you're the gullible type, chances are you don't have a good password policy, or you could be tricked into visiting a malicious website, or both.

But why not just send infected videos or pictures to everyone?

Let's assume the spammer has developed, or found, a program that helps with automatically dialing phone numbers.

If they're sending an infected video or picture to multiple recipients, they may quickly run out of data. It's far cheaper and easier to target people individually, especially those gullible enough to call the number.

In fact, if they target everyone, then that also increases the chance of their scam becoming well-known. By limiting their attacks only to the gullible, they've found a very good way to limit detection and knowledge of their particular scam.

The reason why they'd want to limit knowledge is that many folks may be searching for a particular scam, not exactly their specific scam. This is a problem with many gullible people: they can't really think outside the box, and not realize it's the same type of scam, but with different features.

Your information helps scammers engage in Social Engineering tactics

Have you ever tried to contact customer service for anything important, such as banks, online game accounts, websites, etc? Usually, they need specific information from you, or someone pretending to be you, in order to handle your request.

In fact, just recently, I was able to social-engineer a customer service representative for an account of mine by providing details on things I knew about me, without actually providing any real concrete details, or even providing my identity. All I needed was a few bits of information about myself.

Social Engineering is a tactic used everywhere, and often results in  astounding success because people in general are ill-equipped to handle it. If a spammer has your phone number, then it may be possible for them to get other information. Maybe your phone number is tied to different accounts.

Maybe they have a partial database of credentials stolen from various websites, which could include more information on you. Maybe that database includes information on your email address, which will allow the scammer to continue their campaign of phishing without you realizing it.

Can calling spam numbers cost me money?

  I have heard (no idea where), that some numbers when called, will charge you an enormous bill. Could this be true?

Yes, this is possible.

If you're calling a premium-rate telephone number, then that could cost you a lot of money when you call them. If you text a number associated with a "donation", whether it's legitimate or a scam, your phone bill will likely include additional charges.


What is the point of escaping an interpreter's sandbox?

Consider JavaScript. Most web pages these days serve some JS. Your browser executes this JS, without any user prompting or other permission (unless you use an extension like NoScript), any time it loads a page that contains script. The browser's JS engine is extremely powerful; you can (for example) emulate an entire x86 Linux computer in it. It can also define classes, pull in external scripts, start background workers, and so on. Yet this is, for the most part, safe to do, because the browser sandboxes JavaScript. You cannot, without a sandbox escape, do things like "modify the user's documents" or "deploy something malicious such as ransomware" or "get a shell on the OS running the browser".

Another example, relevant to your examples, is the Java applet sandbox. Java applets are rarely used today (partially because people kept finding sandbox escapes for them, so it wasn't safe to enable!) but for a while they were quite popular because they let you do stuff that was both much more advanced and somewhat faster than the JS engines of the day (and they let you write code in Java, which even then was much more mature than JS). Applets are made of Java bytecode and execute using the JVM, same as any other Java application. The difference is, they are sandboxed so that they can only do things considered safe for a web page to do. For example:

  • They cannot access client resources such as the local filesystem, executable files, system clipboard, and printers.

  • They cannot connect to or retrieve resources from any third party server (any server other than the server it originated from).

These protections mean that code running in an applet cannot simply invoke Runtime.getRuntime().exec(); even though that class and functions exist in the JVM, and can be called from normal Java apps, trying to call them from a sandboxed applet would through some kind of SecurityException. If you want to do that without getting an exception (for example, to run some malware), you need to escape the sandbox.


Hydra sometimes fails against my own router known password

Apparently, that router's web server is not very well implemented, and vanhauser updated his code in order to handle it.
This was my issue (now closed),

https://github.com/vanhauser-thc/thc-hydra/issues/18


What is the most secure way to lock a Linux Distros Desktop?

Use the first screensaver for X servers: xscreensaver.

All the vulnerabilities that the new screensavers recently fell victim to were first found in xscreensaver, fixed and forgotten. They (both KDE and Gnome guys) try to reproduce the functionality of this software without looking at its mistakes. The sad part: they do this just for the bling.


What's the benefit of hybrid cryptosystem vs asymmetric for small data blocks?

If you have messages to send, and you use an asymmetric encryption algorithm, and that algorithm happens to be able to process each message wholesale because the messages are small enough, then indeed you can design the protocol without any recourse to extra symmetric encryption.

However this may lose some flexibility, and have a non-trivial performance cost. The flexibility is about the possibility to replace, in an ulterior version of the protocol, the asymmetric encryption algorithm (e.g. RSA) with another algorithm that can only do key-exchange (e.g. Diffie-Hellman); in the latter case, you absolutely need to couple it with symmetric encryption.

For the performance, a critical point is whether you envision two parties to send to each other several messages in a short time. With "pure RSA" and a 4096-bit RSA key, each encrypted message will need 512 bytes. With an hybrid system, successive messages may reuse an already negotiated session key, and thus need only 120 bytes or so (if the plaintext messages are about 100-byte long). Of course there is also the issue of CPU cost (RSA-4096 decryption are not exactly free), but network bandwidth issues are often more important.

Take note that if several messages are sent and each of them is encrypted separately, then it is your responsibility to include in the messages something which allows the recipient to detect whether some messages were dropped, or duplicated, or arrived out-of-order. You may also want to add some specific countermeasures to detect alterations of messages, and completely phony messages.

More generally, with RSA encryption, the public key is public, hence everybody can use the key to encrypt messages. If you have a notion of a "stream of messages" then you will need some more crypto to avoid external insertion of extra messages. This is linked with notions of authentication. There again, systems that rely on hybrid encryption can reuse an initial handshake procedure, and thus guarantee that all messages protected (through symmetric encryption and MAC) with a given session key all come from the same source.

To sum up: you should use TLS or DTLS. Designing your own protocol is a path fraught with perils.


Multiple Iterations - This helps.  Its called key-strengthening and it raises the computational complexity.  E.g., if you key-strengthen by a factor of a 1000, an attacker can try 1000 less possible passwords in the same amount of GPU/CPU time.
Multiple hash functions - In theory this helps but not really in practice.  The case would be if one hash function used is somehow broken (e.g., you can reverse any 256-bit hash by trying significantly less than 2256 passwords or can significantly simplify the brute-forcing process while trying common passwords), but the other hash functions used in the chain are not broken.  E.g., that your attacker has broken iterated sha512, so can quickly come up with a password that works for sha512 key-strengthened N times, but not sha512(salt||bcrypt(salt||sha512(salt||pw))).  However in my view with modern cryptographic hash functions and typical attackers, that's a fairly unlikely attack scenario -- there are much lower hanging fruit that don't require the attacker to be make fundamental advances in computer science.    Possibly NSA or serious academic computer scientist may come up with clever ways to break hashing algorithms, but not your average malicious attacker.  Also even among hash algorithms that are broken and should generally be avoided (e.g., MD5 and SHA-1), they are usually only broken to collision attacks (find a pair of distinct strings s1, s2 that satisfies hash(s1) == hash(s2) much quicker than expected), but not preimage attacks (given a hash h find an s that satisfies hash(s)=h), which is the relevant attack on a password hash.
Salt mixing - This is an implementation detail, and doing it adds no complexity to an attacker.  (Precomputed rainbow tables for complex key-strengthened salted hashes don't exist.)
Unique schemes - Again an implementation detail, and adds no security.  Also don't run bcrypt multiple times; that's silly.  Bcrypt is already key-strengthened.  E.g., if you hash using bcrypt with a cost of 16, that means the key went through 2^16 ~ 65536 rounds, so if you want a stronger hash just increase the cost (every increase by 1; means bcrypt will be twice as slow).
Black Magic - As a programmer, I wouldn't suggest doing this; as black magic is a maintainance nightmare for you and your team, and again not too significant for an attacker to overcome.  Decision comes down to adopt a new technology, so you have to rewrite the non-standard hash routine in a new language on a new platform and unless its very well-documented you may do it slightly differently breaking the system.  And if it is well-documented, an attacker may steal your source code; see what the function does to a password and then can use for their brute forcing.  If they manage to steal your hashes, they probably have at least one account where they know a password and stole the hash, so can try reverse engineering it (even if they didn't get the source code).  Its like obsfucating your source code on your own server.  Its more a hassle for you the developer/maintainer, not really for attackers.
Obsfuscation - Don't do this.  See black magic.  Or just operate on Kerckhoff's principle aka Shannon's maxim: make the system strong even if the enemy perfectly knows the system.  Obfuscation/black magic can be overcome with a little analysis and provides some security (defense-in-depth), but not much.  However, a strong key-strengthened cryptographic hash with a high-entropy initial passphrase/password can easily be built to have a computational complexity that is completely unfeasible to attack with all the computers in the universe for thousands of years, without major advances in computer science (e.g., quantum computer or breaking the hash function).

  In the end whatever is done with the password it will not prevent someone using a stupid password (like 'password' or '123')

Actually I'll disagree on this one.  Depending on how captive the audience is (e.g., workers must use it for their job), you could invalidate simple passwords whenever a new password is setup (e.g., check against a leaked password list of a ~million common passwords and invalidate all matches, or doesn't pass other minimum standards: must be 8+ characters with upper/lower/number/symbol or a 20+ character passphrase).  Basically, if its a secure application that has serious repercussions for your end if an account is breached, something like this is a great idea.

Granted users will have negative user experience if you are too strict (so if you are a simple web app or an online retailer that wants lots of users and doesn't really worry about accounts being stolen from weak passwords, you probably do not want to implement strict password rules; but the retailer should do things like require re-entering credit card information after the email/shipping address changes and should send an receipt email after all purchases).  Also, beware this ultimately weakening security by users posting the password on their monitor in a common work environment; so make it clear that there are consequences to a user's account being breached.


Why is CSRF protection only applicable to web services with browser clients?

It comes down to the fact that CSRF is an attack against browsers, so if your service is exclusively used by non-browsers there's no point in using anti-CSRF defences, which can be expensive so may be worth disabling.
When a browser interacts with a server, each request comes in separately, so if the service wants to have authentication it needs to add in some scheme to connect requests (to avoid having to have the user authenticate every request). One common way is to set a cookie to the user's browser, which is automatically send when every subsequent request by the browser).

Client logs into service
Server sets a http-only cookie
Malicious script in browser sends a request to e.g. transfer money to the attacker (browser automatically attaches cookie)
User loses money

vs. with protection

Client logs into service
Server sets a http-only cookie
Malicious script in browser sends a request to e.g. transfer money to the attacker (browser automatically attaches cookie)
Server rejects the request as the it doesn't have the correct CSRF fields.

However malicious scripts can make requests to the server, and the browser will helpfully included the cookie. However the script won't have access to the cookie directly (assuming the right cookie option is specified). Therefore a protection against CSRF is to have something in the request separate from the cookie (i.e. a hidden field on a form) that can be verify the request came from a proper form, rather than a script.
CSRF relies on the browser sending the cookie with a cross-site request automatically,  since Javascript/attacker's site don't have access to the cookie.
CSRF protection relies on the server correlating something the browser sends automatically (the cookie) with something in the form (the token).
A non-browser client will be in control of both the token and the cookie so can make them match (if it can get the cookie at all). So there's no point having complicated CSRF protection if the service is never going to be accessed by a browser.
TL/DR - CSRF is inherently a browser attack, so protections against it are only required for services that might be accessed by a browser.


There are several techniques to check whether the domain fbsbx.com is owned by Facebook.

WHOIS record

Let's check the WHOIS record for fbsbx.com:

Registry Registrant ID:
Registrant Name Domain Administrator
Registrant Organization Facebook, Inc.
Registrant Street   1601 Willow Road,
Registrant City Menlo Park
Registrant State/Province   CA
Registrant Postal Code  94025
Registrant Country  US
Registrant Phone    +1.6505434800
Registrant Phone Ext:
Registrant Fax  +1.6505434800
Registrant Fax Ext:
Registrant Email    domain@fb.com

fb.com is one of Facebook's domains, and the registrant organization is Facebook, so that looks legit.

DNS record

dig NS fbsbx.com

;ANSWER
fbsbx.com. 52794 IN NS a.ns.facebook.com.
fbsbx.com. 52794 IN NS b.ns.facebook.com.

The nameservers are on the facebook.com domain, which also looks legit.

TLS certificates

https://lookaside.fbsbx.com/ delivers a certificate issued for the following domains:

*.facebook.com
*.facebook.net
*.fb.com
*.fbcdn.net
*.fbsbx.com
*.m.facebook.com
*.messenger.com
*.xx.fbcdn.net
*.xy.fbcdn.net
*.xz.fbcdn.net
facebook.com
fb.com
messenger.com

So whoever owns fbsbx.com also has access to a valid facebook.com certificate.

The domain is legit.

Be warned that the PDF linked in the post may still link to phishing sites.


I mean they cannot steal my Paypal credentials because they are
  encrypted, all they can do is access stuff which is not that important
  to me in the first place.

This is a huge assumption.

An attacker could use something like sslstrip to change all references of HTTPS to HTTP. It is quite common for websites to serve content via HTTP and use an HTTPS login. The attacker would force you to use plaintext, while then retransmitting the data to the target site with SSL.

The attacker could also present your browser with a fake certificate when trying to access a secure site. While this would normally trigger a warning in your browser, it poses a security risk to most users. Companies often implement self signed certs poorly, and train their staff to acknowledge the warnings. This creates complacency that can leak into their personal life, as they are conditioned to see these warnings as nothing but a step in getting to their final destination.

So while a power user may not fall for some of the tricks posed, its quite possible that the average user could have important credentials stolen with these attacks pretty easily.


So long as you use VMware with care it should prevent malware from affecting your host machine. That is unless the malware has a VM to host escape exploit, but they are relatively rare.

Some precautions you can take are as follows:

Don't connect the VM to your local network
Don't mount host folders or disks to the VM
Disable host-VM interfaces such as shared folders

You may find this guide useful: https://zeltser.com/build-malware-analysis-toolkit/


Lockouts after a set number of failed logins creates a DoS condition, where an attacker can efficiently prevent anyone from logging in. You also need to account for low-hanging-fruit attacks, where one attacker tries the 3 weakest passwords on every single account.

You should create a system that increases the delay between allowed login attempts up to a certain limit. A common choice is 1 second after the first failure, 5 seconds after the second, 20 after the third, and 45 seconds for all subsequent attempts. This should be the case per-account and per-IP.

CAPTCHA images are generally useless, since you can pay people in the 3rd world miniscule amounts of money to solve them, or set up phishing attacks to get unsuspecting users to fill them out for you. Besides, users find them annoying and they're often not solvable even by humans.

I highly recommend checking out The Definitive Guide to Forms-Based Website Authentication for a detailed and thorough description of the security methods you should consider.


Methods to detect calls being routed through Stingray devices?

Can't see anything for iOS but there is an app for Android that claims to be able to do this. However, it only works with a specific chipset and only on a rooted phone. So it is very unlikely that you could do this on an Apple phone. Another app is in early development.

There are also dedicated systems for trying to track stingray use. A "homemade" example is here.

In theory, you might be able to track use at a static location by knowing the ID's of the local stations so that you can spot when a new station ID appears.