How to determine if a browser is using an SSL or TLS connection?

There are several protocol versions : SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. Internally, TLS 1.0/1.1/1.2 are SSL 3.1/3.2/3.3 respectively (the protocol name was changed when SSL became a standard). I assume that you want to know the exact protocol version that your browser is using.
Internet Explorer
According to what is described on this blog post, Internet Explorer can display the protocol version information. Just hit File->Properties or Right-click -> Properties, and a window would open, under Connection, you'd see something like:

TLS 1.2, RC4 with 128 bit encryption (High); RSA with 2048 bit
exchange

Firefox
As of today, Firefox supports TLS 1.0, TLS 1.1 and TLS 1.2. You can see the negotiated protocol version if you click the padlock icon (on the left of the URL), then More Information and then under the Technical Details.
Chrome
Chrome can display the version.
On earlier versions of Chrome, click on the padlock icon; a popup appears, which contains some details, including the protocol version. example: (verified on version 21.0.1180.82)

The connection uses TLS 1.0

On later versions of Chrome, this information in the security tab of the developer tools. (Credit to nickd)
Opera
Opera shows the protocol version in a way similar to Chrome: click on the padlock icon, then click on the "Details" button. e.g. (verified on version 12.01):

TLS v1.0 256 bit AES (1024 bit DHE_RSA/SHA)

Others
For browsers which do not show the information, you can always obtain it running a network analyzer like Wireshark or Network Monitor: they will happily parse the public headers of the SSL/TLS packets, and show you the version (indeed, all of the data transfers in SSL/TLS are done in individual "records" and the 5-byte header of each record begins with the protocol version over two bytes).
And, of course, the actual protocol version is a choice of the server, based on what the server is configured to accept and the maximum version announced by the client. If the server is configured to do TLS 1.0 only then any connection which actually happens will use TLS 1.0, necessarily.
(Edit: I have incorporated some information from the comments; done a few tests myself. Feel free to enhance this answer as needed.)


I'll go out on a limb and guess that any directory your user has permission to write to is mounted as noexec, which means that you will not be able to directly execute anything. To run a shell script despite this, you can always do bash script.sh if doing ./script.sh fails with a permission denied error. You should try looking for any directory you can write to which you can also execute from. If none exist, then even having gcc would not help you, since you could not execute the code it generates.

In order to exploit DirtyCow, you need to invoke a number of system calls. This cannot be done from within a shell script. You either need to use a sufficiently sophisticated scripting language such as Python and re-write the exploit in it, or you need to compromise a binary that you have the rights to run and make it run shellcode to perform the attack. If you aren't able to do that, I suggest you practice binary exploitation and shellcode development first to learn how, or this will be quite hard.


Is it easy to create persistent programs that run before Android's boot? (in firmware maybe)

If the bootloader is locked, all android partitions are verified by android verified boot (AVB) and android bootloader (ABL) is verified by secure boot which is enforced by chipmaker in production SoCs. Devices with Qualcomm Snapdragon SoCs, Qualcomm's Primary Bootloader (PBL) of SoC verifies Xtended Bootloader (XBL), XBL verifies ABL and ABL enforces AVB.
To break this chain of trust, the attacker can exploit a vulnerability somewhere in the chain to bypass signature verification. One can also tamper with PBL on board. While modifying it may be considered feasible in theory, it is not scalable. PBL is burned on CPU die and its public key is stored in eFUSE which make it tamper resistant. Android has infamous fragmentation problem, most android devices never receive timely updates and new vulnerabilities remain unpatched. Some of the critical vulnerabilities in chipmakers' bootloader and android bootloader were found in the past which could be used for persistent malware and bypass of secure boot and AVB.
If your device's bootloader is locked and has been factory reset then it is running stock image otherwise the device would brick on first boot. The device can also run with custom root of trust where AVB key is user generated. This allows user to make its own modifications and re-sign images to enforce custom AVB. You can see the verified boot state of the device in bootloader mode.
Verified | SelfSigned | Unverified | Failed


An IP number is very comparable to a phone number. By default this is a public information available in any public directory and is necessary to establish a communication.

However there are tons of way to exploit even public information in illegal ways.

So the real determinant here is not the fact that you are collecting the local IP and MAC address, but the purpose you have behind it.


Is an application backend expected to potentially log sensitive customer data when in debug mode?

This is a great question! I'm also a developer on a c++ product that handles high sensitivity data, and we face this dilemma almost every day.

When a production system starts throwing alarms (especially performance or configuration-related ones, thought misbehaving software / bug ones also apply) we often need stack-trace level debugging turned on temporarily in order to diagnose the problem. These logs inevitably contain sensitive information: IP addresses or users involved in the transaction, sometimes pieces of the data, you name it. Often our customers don't feel comfortable giving us these logs for obvious reasons. It's tough.

The administrators actually running your server will know what level of sensitivity their data is, and what government or industry security policies they have to follow when handling it (for example: government, financial, and health data all have special rules). It's fair that your software has the ability to produce sensitive logs, but the admins need to be fully in control of how, when, and where they get produced and stored.

Some things you can do:

Make sure you are very careful to correctly categorize all error messages containing (even potentially) sensitive information into the correct log level - INFO, WARNING, ERROR, DEBUG, TRACE, etc.
Be explicit in your documentation about kinds of sensitive information is included in each log level. The more detail the better so the security-minded admins can do their jobs properly.
Make sure DEBUG/TRACE log level is off in the software's default configuration, and that the admin has to run a gambit of warnings to turn it on (ie it's not possible to do by accident).
You could send DEBUG/TRACE level logs to a separate log stream (you mentioned a separate "secure" log) that defaults to local storage, making it harder to "accidentally" ship it outside the secure zone, or get it mixed in with the standard logs.
Ship your product with a redaction tool that knows how to mask all raw data, usernames, IP addresses, etc from your DEBUG/TRACE logs with unique placeholders (each unique username / IP gets masked by a unique A, B, .., AA, etc). Often the actual username / IP / data is irrelevant, but the key to diagnosing the problem is that the error only happens with data of type X, or that IP address A (and only A) always always sends its requests three times, or whatever. This way an admin can be confident that nothing sensitive is leaking if they ever ever need to move these logs out of the secure zone (for example sending them back to you for debugging).

Bottom line: I think it's fair that your software has the ability to log sensitive information for debugging purposes - and you'll thank yourself later when you have to debug a malfunctioning prod system! But make it as difficult as possible to turn on "by accident". Trust the admins to know their security requirements, and make their jobs easy.


Like a normal (not same-site) cookie the Authorization header for Basic Authentication is always send with a normal HTTP request when the site is accessed and credentials are known, no matter if cross-site or not. There is no way to specify a different policy for this header.


How Can I know Which Files are Transfered From my System through team viewer?Unable to understand log files

First of all, make sure you secure the TeamViewer log files.

Did you find the two files called

Connections_incoming.txt
TeamViewerX_Logfile.log

on your machine? This is where TeamViewer logs its connections.

If you cannot find any log entries there, your suspicion about someone stealing files via TeamViewer may be wrong and you have to look for a different hole in your system.


Signtool validation fails when signing and validating are done in different machines

A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

This message means that you signed the binary successfully and signtool could process the entire certificate chain, but the root certificate isn't trusted by the machine.

What this means, on a higher level, is that signtool knows it was signed but it doesn't know who signed it, and so it's not a very useful signature. If you're using a self-signed certificate, you can fix this by copying your certificate to the target machine and installing it there; a better solution if you want your users to trust you is to buy a code signing certificate from a reputable certification authority and sign your code using that.

Either way, this will mean that the target machine will now know who signed it and be able to verify that the signature is valid.


You will get something like this:

SEQUENCE {
  SEQUENCE {
    [0] {
      [0] {
        [3] {
          ...
        }
      }
    }
  }
}

Explanations:

Even though the tags are supposed to be implicit (due to being in a module declared with IMPLICIT TAGS), implicit tags cannot be applied to a CHOICE (because otherwise the CHOICE would not work at all), so they are automatically converted to explicit tags in that situation. Here, the [0] tag on the distributionPoint field is in such a situation, so it wraps around, instead of replacing, the tag of the DistributionPointName field, which is also a [0].
Notice that fullName has type GeneralNames, not GeneralName. You do not quote GeneralNames in your message; it is a SEQUENCE OF GeneralName. The [0] implicit tag of the fullName field, being implicit, replaces that of the SEQUENCE.

For the first point, it is specified in X.680, clause 28.6 (from the 1994 version):

  The tagging construction specifies explicit tagging if any of the following holds:

  a) the "Tag EXPLICIT Type" alternative is used;

  b) the "Tag Type" alternative is used and the value of "TagDefault" for the module is either "EXPLICIT TAGS" or is empty;

  c) the "Tag Type" alternative is used and the value of "TagDefault" for the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type defined by "Type" is a choice type, open type, or a "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, clause 8.3).

The last clause (c) is what I explain above.


How to secure a web service for web applications using same database?

My problem is that I don't want anyone else to be able to use the web
  service. Meaning that only the applications should be able to call the
  web service to get information or execute an action on another
  application.

  Is there any "simple" way to do that?

There are several ways. You say you use HTTPS; so you can add a simple authentication scheme (shared secret) with very reasonable safety. I assume the applications themselves are secured.

You can also perhaps employ client certificates for the SSL conversation (i.e., the SSL channel also supplies identity certification). Depending on your setup, it might be easier to implement than adding authentication to the web service.

Possibly, you can use an authenticating proxy. This requires a more awkward setup, since you're in practice using the proxy to run a man-in-the-middle attack against your own SSL connection. Or you can use some sort of web service-aware front-end developed for that purpose, that would do essentially the same (identifying itself as the real web service, then passing the connection to the real web service after removing extra authentication information).

In all cases, you can reduce the attack surface by routinely denying access to the services at the IP level, unless the requests come from a neighbourhood of known application installations.

A specialization of this approach would be to establish a full VPN between applications and web service. This would have the advantage that neither apps nor web service would require any substantial modification, but would come at some performance cost (you're running an encrypted connection inside another).

  I figured that since only the applications have access to the
  database, I could probably use it as a trusted third party to validate
  the identity of the one calling the web service.

You can, but at that point your applications are already communicating with the system running the web service through the database. Whatever channel you're using for the database, you can either use that same channel/method, or you should suspect it to be insecure.

For example, the applications (or the service) are now accessing an external database server - can anyone access that server? If yes, you might have some problems right there. If not, which is more likely, then why? (And I guess the answer is "SSL encrypted connection, password/certificate authentication, and/or IP verification, or full VPN").

Update

In your setup, the applications and the web services they expose are on the same machine (this is not so common, which is why I hadn't thought of the possibility). This allows for 'trivial security' -- i.e., you can expose the web service interface(s) on 'localhost'. You can even use them in the clear, dropping SSL altogether, since localhost communications won't leak outside the machine. And to intercept them one would need a sufficient level of access to the server that the point is moot anyway.

If you want, or if you ever need that, you can also expose a (different?) web service on the external interface, and run that endpoint with authentication and SSL security (possibly with client certificate check also).

As things stand, it seems to me that you are already secure. Just check that the applications/frameworks/servers default configuration does not include binding to any interface (it is very often the default), because that would potentially allow access from outside.


How did my network admin identify my iPhone and how can I hide my ID?

There's any number of ways that your company's network administrator may have identified you. The principal thing you need to realize is that, while you may be using your own device, you are on your company's network. That grants the company a lot of visibility to the traffic your device generates, should they choose (as it appears they have) to examine it. It also means that you are responsible for complying with your company's policies regarding efficient and appropriate use of their resources (e.g. bandwidth).

The easiest way they could have identified you is by your device's hostname. If it's called "Chuck's iPhone", and you're the only "Chuck" in the office, it's not a huge leap to figure out whose device it is. Changing your hostname is perhaps the simplest thing you can do to obfuscate your identity.

Another way to identify the device is by registration. Your company may have forced you to register via a web portal when you joined the WiFi network. At that time, your iPhone's MAC address could have been logged. Though it's possible to change a device's MAC address, it's rarely done. So it's still a fairly reliable identifier, if you have data to associate it to a person. I'm not aware of any built-in mechanisms to change the iPhone's MAC address, but I've heard there's supposed to be a feature coming in newer iOS versions.

If your phone is making any connections to other corporate systems (e.g. e-mail) while you're on their WiFi, your connections to those systems will be logged. That will associate your company username, which is associated with your identity, to your iPhone's current IP address. The first step to avoid this is to stop using company applications on your phone when you're on the company's WiFi network. (Also make sure that you don't have any apps installed or configured in such a way that they might do so in the background.) The next step, after you've done that, is to get a new IP address. Since you don't know how the DHCP server is configured, the best way to do this would be to disconnect from WiFi, delete the WiFi profile, change your MAC address (if possible), rebuild the WiFi profile, and reconnect. Then, check to make sure that you got assigned a different IP.

The last way they could identify you, which is generally the most difficult to mitigate (especially on a non-jailbroken iPhone), is by direct analysis of your network traffic. Smartphone applications send a lot of data in the clear, both when you're actively using them and when they're running in the background. This data can contain any number of things that might be used to associate the phone to you, personally. It could have your name, user account IDs for online services (which may be based on your name), names of your friends/family, pictures of yourself or friends/family, phone numbers, addresses, or various other flavors of PII. Unless you've personally vetted how every application on your iPhone handles your data, there's no way to know for sure what information might be readily available to the administrators of any network your iPhone connects to. The only way to avoid this is to route all of your iPhone's traffic through a secured VPN gateway. These usually are paid services, and may or may not support your device.

In the end, we come back to what I said in the first paragraph. The company's network is not yours to use however you choose. Especially now that you've been warned, any attempts you make to circumvent their management systems will only further strengthen a disciplinary case against you. Also, just because you might be able to make yourself unidentifiable via network traffic from the data-link layer or above, there are no measures you can take to prevent a network administrator from identifying you at the physical level. With enough access points acting as sensors, network administrators can isolate your device's location to within several meters and follow it as it moves around. This can be used to build an activity profile which could be roughly correlated against your personal work and meetings schedule. To further narrow it down, a tablet or other man-portable device can be used to find your device's location within a few feet.

In short, the best way to keep your personal device from being identified on the company's network is to not use it on the company's network. Keep your personal devices and Internet activities off of corporate hardware, and your network administrators won't care what you do with them.


After it's done, the cryptolockers waits a few weeks and activates itself so there is no present back-up available. If a user tries to open a document in the waiting period, the cryptolocker quickly decrypts the file so you wont notice the encryption.

This does not make much sense. A backup process would also try to access the file, so the file would be decrypted during the backup and thus the backup would contain the original file.

  Someone said ...

Always ask for the source of such a claim. Just because someone on the internet said something it does not mean that it is correct.

Maybe whoever said this has read about cryptolocker which waits before activation, like described at Locker: Cryptolocker Progeny Awakens. But this is about remaining silent for a long time and only after some time starting to encrypt files. By deferring activation until a specific date the ransomware evades dynamic analysis because it does nothing bad for now. It thus can spread without getting detected before all sleepers get activated at the same time.


Does Letsencrypt support any challenges that don't require control over HTTP or DNS?

It had, over HTTPS port (443):

TLS-SNI-01

But for security reason it's now (mostly) disabled:

https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811

https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209

TLS-SNI-03 is in progress:

https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03

But it's not yet available


Ensuring security in Token url authentication

What you've got sounds at a basic level, how many people handle password resets.  A couple of things to consider.

Tokens should only be valid for one user. i.e. you shouldn't have a pool of "valid reset tokens" but a list of token-->username mappings. So when someone accesses page one you can tie that to the account they should have clicked the link from.
when the user successfully uses the forgotten password link, after checking their token you should set a session token for them, and then check for a valid session token when loading the second page.  That way if anyone tries to directly access the second page they won't be able to use it without a valid session
you should pre-populate the E-Mail ID for the second page based on the user who's token is being accessed.  Otherwise there's a risk that one user can reset anothers password.
Once the token has been successfully used you should invalidate it to prevent someone who comes across it in future from resetting the users password again
You should have an "unused" token expiry to prevent them from being permanently useful.
One user account should only have one valid token at a time.  If a user has one issued, and they go through the process again it should overwrite the first token.


Does "Certificate Authority" refer to the organization or the software?

When speaking about a trustworthy "Certificate Authority", we refer to the organization/entity issuing the certificates, and not the tool used to generate them. It refers to the entity in the "Issuer/Issued by" field of your certificate (e.g. DigiCert for this website). Thus, if you issued your own certificates using the same tools as DigiCert, say OpenSSL, you would still not be a CA trusted by most browsers. You could, of course, be a trusted CA within your organization/network/device group.


Dealing with excessive "Carding" attempts

Given that you have strong verification of name / address, etc., it's most likely that your site is known to return different values for different types of errors. The best thing you can do to discourage card testing is to ensure that any declined transactions provide the same result regardless of the reason that the processor told you it was declined.


undocumented options for -inform / -outform for rsa / OpenSSL?

Unfortunately proper documentation is not one of the strength of OpenSSL (and it shares this weakness with many other software). The parsing of the options is done in apps/opt.c function opt_format. Not all of the possible options are implemented for rsa but looking at apps/rsa.c I see mention of PEM, DER, MSBLOB and PVK.


How could a public DNS server return bad results?

How are they (ISP) achieving this, Are they really stealing and MITM ing the traffic of 8.8.8.8?

They probably simply redirect all packets with destination port 53 (i.e. DNS) to their own servers and answer the query themselves. This is not that hard to do.

  How can I get around this without VPN?

A properly configured VPN (i.e. no DNS leaks) can get around this (unless they block VPN too). Also using a HTTP proxy or SOCKS proxy can help (make sure to configure external name resolution for the last one) for HTTP and HTTPS traffic. And DNS privacy techniques like dnscurve, dnscrypt, DNS over TLS and DNS over HTTPS (supported already by Firefox) will help too.


Link shortener that virtualizes link for reflected XSS?

Ordinary URL shorterners are commonly used to hide the payload and make links look less suspisious. However, they do not help against the browsers XSS filters, since what an ordinary URL shorterner does is simply issuing a redirect.

You suggest an approach to bulding an URL shorterner that does bypass the browsers XSS filters using what you call virtualization instead of redirects.

The way to do this virtualization would be using an iframe. The only problem is that the browsers XSS filter will (probably) be protecting the iframe in the same way that it is protecting you when you enter a URL in the URL bar. So you don't win anything.

And using an iframe is the only way I can think of doing "virtualization" without running into the SOP. So I don't think this is a viable concept.


Behavior of trusting a self signed SSL certificate

The only difference between a self-signed cert and one issued by a CA is exactly that, the self signed cert is not issued by a CA.  If you trust yourself, then you can trust your "self-signed cert".  It will protect you from MITM as long as you have SSL/TLS configured correctly on your server (ie: you do not accept null ciphers).  When it expires, your browser will issue the same warning that you would get if a public CA signed cert expired.


As @Adnan says, the worst is "Full compromise and the existence of a backdoor.". Why? While playing with SQL alon can't lead to any compromise of the system itself (just reload the datatabase from a backup and you ought to be set), the programs using SQL and interacting with the system have much higher capabilities.

For example, there's a chance that you have a table containing PHP template snippets. An attacker can edit that and add malicious code. If anything from the SQL tables is being executed (or even dumped to a file -- if the file can be dumped to the web folder, then an attacker could use it to inject and run his own PHP), then you may have a problem.

So find out where all the data in the tables is used. If, at any point, it is being saved or executed, see if this is exploitable (in the case of the former, it depends if the attacker can put arbitrary text in the web folder using it. In the case of the latter, it's almost always a problem). If so, there's a chance the system was compromised, and you may want to do a clean install.

If not, then just look for problems in the tables and fix them if present. Make sure you change your username/password (and check for rogue accounts)

An interesting thing to note is that in SQLite, the ATTACH DATABASE command can be used to directly introduce vulnerabilities.

Similarly, the SPOOL command in SQL* Plus can be used if the injection allows for multiple commands to be executed.

If you're using either of the above two, a clean install would be good regardless of how the data is being used.


Intercepting messeges in attacks on authentication protocols

Lets look at a client server example like a website. The client (browser) communicates with a server (web site). The "Man-in-the-Middle" (MitM) in this case convinces the client that he is the server, so the client thinks it is talking to the website. The "MitM" also convinces the website he is the client. Communication is then completely controlled by the "Man-in-the-Middle".

For a low tech example think about a King communicating with a General centuries ago, by having a messenger carry letters between them. It is not just that the messenger can read the messages, but lets say the messenger can forge the King and General's handwriting. The messenger can then pretend to be the King to the General, and the General to the King. Controlling all communication.

This can happen in many ways (in fact any non-in-person communication should have some measures to prevent MitM attacks), so it is not a "general" networking question.

But for one simplified real example that includes networking: if we are both at a coffee shop, I (armed with some software and a wifi adapter) can pretend to be a wifi access point (AP), and display it as "Cafe X - Guest Wifi (Free)", in hopes someone will connect. If you take the bait, then I can act as the MitM for all your communication -- intercepting and injecting packets.


How easily could be truecrypt and EFS cracked in this scenario

Physical presence of an attacker is the hardest to defend against. Some products consider "physical presence" as sign of ownership and allow full rights to the person in front of the machine. For example, motherboards that allow to reset BIOS passwords so as not to lock out an user who forgot his password.

The EFS + TrueCrypt solution is good but it depends on the security of your passwords. Your data is encrypted safely but your passwords are not protected against interception. Keylogging is a simple way of intercepting your passwords but most known keyloggers will be detected by an Antivirus. The attacker can run a program on your computer that looks like TrueCrypt and will send your password to the attacker.

If you leave your computer unlocked in a hostile environment, you cannot have any expectation of privacy and security. There is no way to be 100% sure that you can detect and disrupt an intrusion after the fact. Locking your computer is very easy and you should make a habit out of doing it. Pressing Windows key + L will lock Windows and CTRL + ALT + L will lock most Linux desktop environments.

EFS in Windows Vista and later will encrypt pagafile.sys but not hyberfil.sys which can be used to extract TrueCrypt keys.

TrueCrypt Unencrypted Data in RAM:

  Microsoft does not provide any appropriate API for handling
  hibernation and shutdown, master keys used for system encryption
  cannot be reliably (and are not) erased from RAM when the computer
  hibernates, is shut down or restarted.

Use TrueCrypt full disk encryption to encrypt all of your hard drive.

One weakness of TrueCrypt full disk encryption is when the attacker has physical access multiple times. The attack goes by the name Evil Maid and is mitigated by the use of TPM. Basically, the attacker modifies the TrueCrypt password check code to store the typed password in cleartext for later retrieval. The same goes for other full disk encryption products. Use TPM features if your laptop provide them. Take your laptop at home or lock it with a key if you want more security than Truecrypt can provide.

Update:

One ingenious solution for automatically locking your computer is using this program:  http://stevetarzia.com/sonar/. It uses echoes to "see" if you are no longer in front of your computer.

There are similar solutions using the webcam. https://www.keylemon.com/product/


Local IndexedDB in Browser - is it really a security risk?

When we subjected it to Penetration Testing, a finding was filed saying that "Senstive Data such as Database Name, Storage and Version were found stored in the local IndexedDB".

The people who performed your pen test should be providing you with some evidence, screenshot, full/redacted values they obtained. It is possible they just ran an automated tool that say some form of local storage and they just complained about that in general. I would go back and ask them to clarify exactly what they found and why its a problem.
As client-side storage, I would assume the data present will depend on the client and what they were doing in the app. The DB may be empty when you visit, but maybe the account they used for their attack had access to other data.
If you have third party JavaScript which is allowed to read from IndexedDB and you store an API key or something like that there then the third party script could obtain it, in contrast to using a cookie with the httponly attribute.


How does a Safenet eToken Pass(hardware token) generates OTP and based on which algorithm? How does authentication takes place against it?

Supposing the counterpart knows your PIN, and the initialization vector for your eToken, then all that it's needed is that the eToken has a clock.

Using some amplification scheme, possibly involving the IV again, the timestamp (usually with one minute resolution) is converted into a large enough buffer to undergo encryption inside the eToken. From that, a token is extracted and shown on the display.

When you send your username, PIN and eToken data, the server simply runs the same calculation using the IV it has in its database, and verifies that all the data match (optionally, the token values for one minute before and one minute after the present time may be tested, in order to correct small clock drifts).

--> username, PIN   -->      "user suraj has IV 12345 and it's now
                              june 10, 2016, at 17:12. Encrypting
                              this date with 12345 yields a number
                              whose last six digits are 488690."
--> token 488690    -->      "YES! You are logged in."

Using standard six-digit eTokens, and without access to the IV that was burned into the eToken memory, there is one chance in a million that an attacker is able to generate a valid token, even if he did have your account login and PIN.

(Usually, also, these systems will lock after three or five attempts to enter an incorrect token).


Hybrid Encryption: What is the format for storing the encrypted key and the cipher text together?

Email encryption has faced the same problem and come up with two solutions.

You might want to look into PKCS#7 aka the Cryptographic Message Syntax (CMS). It allows for storage of not only the encrypted AES key but also certificate information (issuer and serial number) to identify which public key was used for encryption.
Alternatively, PGP has a very similar system with its own message syntax. PGP also stores a key identifier to tell the decryptor which public key was used for encryption.

Both formats can be stored as BLOBs or CLOBs to work around database column size restrictions. Both formats also support message signatures, should you need that, too.


Blackbox URL matching mechanism bypass for an open redirect

I would try the following:

directory traversal ../../foo/bar
different encodings, url etc
padding with null bytes and extra chars
general fuzzing, including extreme length, multiple char sets and encodings, sql fuzzing (in case it is pulling the valid redirs from a db)


Online Shop got hacked, fixed but is still under attack - what to do?

I would do a few more things to clean up the site:

Change every password

Yes, before you do anything, change all admin passwords, ftp, ssh, MySQL and so.
Move all website's files to an inaccessible folder

Take the site offline and put a Under Maintenance sign to give you time to fix everything. This will disable any changed file from the attacker. Shells will be unusable too.
Reinstall xt-commerce from scratch

Patching the current xt-commerce is not enough. There are plenty of places to put a backdoor, and it's easy to bypass one even with very careful examination. If there's custom themes or plugins installed, reinstall from scratch. Try don't copy any of the resources from the old site, treat them as infected. Don't try to fix any infection, create from scratch.
Patch the new xt-commerce to use a better password storage

If the default password storage from xt-commerce does not implement salting, something is very wrong. Salting is required for every password management since the launch of Intel Pentium MMX. Or even earlier.
Take a full database dump and inspect it for signs of abnormalities

Any sign of eval, replace, decode, exec or system will be suspicious. Take a close look on those entries.
See if there's any strange account created

With the database dump in hand, see if any account have more privileges than it should have. Maybe the attacker created a disguised admin account.
Inspect the log files

This will show you how the attacker gained access to the site. As some PHP shells can use POST, custom headers and cookies to send and receive data, the default Apache log configuration can not show everything. Add the %{Set-Cookie}o directive to the configuration to log cookies, and log POST data too.


Monitoring Github/Internet for source code leaks

That's one of the InfoSec / IT Sec issues currently a bit overlooked just like machine code / source code analysis for vulnerabilities and it's quite similar problem.

Basically you can approach problem with two ways:
   - Index and search for the same binary code
   - Index and search for the same source code

Now the problem is that there isn't really search for the source code which could compile and look for same binary code with the same execution sequence.

This is because it's a bit advanced subject, actually, it's the final subject which will allow for automated audits, debugging and so on.
As Elon Musk said himself, that it would eventually lead to the rise of Skynet.

There are some search engines for the code but simply by changing labels in source code you can defeat them.


Is it safe to enable auto-login in Windows with whole-drive Bitlocker turned on?

Is it the safest setup? No.

Is it safe enough for you? Might be, and by the sound of it, probably.

Infosec is not a set of rules to be followed stringently, it's a matter of deciding what the risks are in your specific case, and taking the measures you feel are appropriate to reduce that risk to acceptable levels.
This is assuming you don't have legal or contractual obligations, in that case you will have a list of things you MUST do of course, that's the nature of obligations.

Questions to ask: why did you encrypt in the first place? Will those reasons still apply if you don't require a password to login to windows? Do you always shut down the machine or leave it on stand by?


Are default ACL in Linux a security flaw?

First, there is no "standard Linux ACL". Default file permissions can vary by system and by distribution; most distributions seem to have default permissions of 644 or 664, but that's not inherent to the Linux kernel, and the proper umask depends on the system.

More broadly: whether files are defaulted to world-readable is a security flaw or not strongly depends on what specific threats you are concerned about. If default permissions are world-readable, that means all users on the system can read files not specifically marked private. That's not necessarily a bug -- in a multiuser environment, you could plausibly declare that users will typically be sharing files, and provide a ~/private/ directory by default for files that they don't want to be shared; people can by default read anything directly under your home directory, but on the flipside sharing is easier. There's a tradeoff, which is often worth making.

Furthermore, the default permissions on files don't change on a per-folder basis. If users want to keep some things private and share other things, and don't want to chmod lots of things, you have to set permissive default permissions. You then make certain folders which will have private stuff have more restrictive permissions. You can't do the reverse; if you want to make it possible at all to have someone have a Public directory without learning chmod, you basically have to implement it this way. It's really easy to restrict access to a file beyond what's in its permissions; granting access beyond its permissions is not possible (you have to change the permissions).

That's because you're wrong when you say that a 0700 home directory doesn't secure anything. A folder's x bit controls access within the directory. If a user has no execute permission on /example/directory/, then they cannot access anything within /example/directory/. Even if they know that /example/directory/a is a file. Even if they have read permissions on that file. Even if they own that file: you can't access a file unless you not only have the permissions on that file, but also have execute permissions on all parent directories of that file. The implication is that you can secure a subdirectory much more easily than you can make an especially open one.

In your case, the Documents directory is 700; probably the other "user-friendly" directories (this is an awful term for it, but I mean things like Documents, Desktop, Downloads, Music, etc. -- stuff that's designed for the average user to use to hold their normal files) are as well. Provided you store your documents there and not in custom subdirectories of your home directory (or directly in your home directory), no one else has access. Your home directory is intended to contain mostly config files that are expected to be there; most personal files are meant to go in a default (secured) subdirectory. If you store things directly in a home directory, they're visible, but that's not what your OS is pushing you to do. If you create a new subdirectory of ~ and want it private, set its permissions to 700; if you want it public, set it to 755 (if you want people to be able to access files if and only if they know the name, 711). But the expectation is that your private stuff doesn't go straight in ~, and that the places your documents do go is already secured.


Can a PGP private key be deduced if the email text is known?

No, the private keys are still safe in this case:

Your key, as the sender, is not involved at all in the process. When you encrypt an email to person A, you use A's public key, not your private key. If you use your private key at all, it will be to sign the email you send, which is something quite different.
A's private key is not involved either. You use A's public key for the encryption. If the potential attacker wants to know a message m, and what this message would become if encrypted with A's public key, then... he can do it himself ! A's public key is public, everybody knows it, and everybody can encrypt things with that key.
In the general case of encryption mechanisms, such systems are supposed to resist situations where the attacker can learn several (even many) pairs plaintext/ciphertext. These are called known plaintext attack (attacker learned a plaintext/ciphertext pair), chosen plaintext attack (attacker gets to choose the plaintext, and obtains the corresponding ciphertext), and chosen ciphertext attack (attacker chooses the ciphertext and obtains the plaintext). PGP would be considered quite weak if a single pair, or even one million pairs, would be sufficient to break it.


How effective are reverse proxies as a web application security measure?

Reverse proxies can be used as:

caching server and as a load balancer - that would help in mitigating DDoS attacks at some level;
proxy to hide the real server software from scans and fingerprints;
proxy where WAF or IDS/IPS are setup, thus preventing attacker from further intrusion steps;


PHP and other files on the server, their visibility and access

Under normal circumstances, assuming that the server is configured correctly and that there are no security vulnerabilities in either your server or your PHP code, there should be no way for any normal visitors to see your PHP source.

The reason you cannot hide HTML/CSS/JS from users is because HTML/CSS/JS are all client-side code, meaning they are interpreted and executed by the user's browser. Obviously, you must send the code to the user before the user's browser can execute it, so users can easily make their browsers show them this code.

PHP, on the other hand, is server-side code. This means that your server runs it, and only sends back the results to the user. ("Results", for the most part, means anything you put in echo() statements). Thus, there should be no way for users to look at the original source. They are limited to stuff that you explicitly 'echo' (plus maybe PHP error messages, if you have them enabled).

If someone guesses the URL of a php script and tries to access the URL directly, the server will still just go through and run the script, and send only the output back to the user. The server runs the script each time it is requested. What the user will see depends on the specific script and your server configuration. If the script requires user input and none is provided, then it is likely the user will just see an error message.

  read/write rights are required for the user to actually make the php
  work, or is it fine to take user's r/w access to the php files and the
  website will behave the same accessing the php when user sorts of
  request it using the website?

I have no idea what you mean by this, could you elaborate?


Could this kind of authentication be attacked?

This looks like you're storing passwords in the clear, which is a bad idea. You should ensure passwords are protected using, at minimum, password_hash() and password_verify(), which use bcrypt under the hood. This is simple, easy, safe, and perfectly acceptable for most scenarios.

Alternatively you can use a slightly more secure method such as Argon2, which won the Password Hashing Competition and is resistant to CPU and GPU cracking, and also aims to minimise the potential for side-channel attacks. There's an article which explains how to use Argon2 as part of libsodium's PHP wrapper, or directly using Paragon's "Halite" library, which offers Argon2 with symmetric encryption on top to prevent database-only access from providing usable hashes, due to the fact that the symmetric key is stored on the server's disk as a file. This option is more complicated, but it does offer some additional security if you're truly paranoid. I'd suggest avoiding this if you're unfamiliar with secure development, though, as the chances of you messing something up are increased.

I'd also recommend using === in order to avoid weird cases of false equality using arrays in URL queries or nulls.


How to destroy VOIP phone in a proper way?

Considering every VOIP phone is different, it's kind of hard to standardize depending on where the storage module is located.

There are companies who are specialized in hardware destruction, opting for performing destruction yourself can be very very tricky. Should you be able to locate the storage module you could use the Guidelines for Media Sanitization produced by NIST.


Is there any defense against this kind of attacks? (key comparison attack, or something)

First things first: passwords are not (or at least, never should be) encrypted. They are hashed, a one-way transformation that takes an arbitrary input of arbitrary length and produces a constant-length (for any given hash algorithm), deterministic (the same input always produces the same output), and high-entropy (hard to distinguish from random) digest (also simply called a hash). For cryptographically-secure hash functions, there is no way to tell, given a digest, what input string produced it (and of course, there may be an infinite number of possible inputs that would produce it, since there are infinitely many possible inputs but "only" a limited number - such as 2^256, for 256-bit hash functions - possible outputs). In other words, you cannot reverse a hash function. Additionally, any changes to the input of a secure hash function, be they large or just a single bit-flip, generally produce a dramatic change in the digest.

Due to that, the standard attack on password hashing has long been to hash a large set of candidate passwords with the same algorithm, and check if any of the outputs match the digests in the dumped collection. Originally, this could be done with large, pre-computed lookup tables (called "rainbow tables") where a password, if it was present in the rainbow table, could be identified from its hash easily (simply search the table for the same digest). To protect against that, password hashing algorithms began to incorporate a "salt", which is a random string of bytes that are generated uniquely for each user, and are combined with the user's password when hashing. This makes rainbow tables useless unless the attacker already knows the salt of the user they want to crack, and even if they do they can only crack that specific user's password and have to generate an entirely new set of hashes for each other password. It also means to users who use the same password will have different digests, as their salts will be different.

However, even salted passwords can fall prey to a simple brute-force attack, because secure hash functions are generally optimized for performance (many of the places they are used, such as HTTPS traffic, require that they be computationally inexpensive). Chips that are optimized for performing the same operations on many distinct pieces of data in parallel - which is exactly what GPUs (graphics processing units) do - can brute-force an enormous number of hashes in a very short time (high-end GPUs can compute billions of hashes per second, for some of the common hash functions). Very, very few users are going to select a password so rare it's not one of the first few billion attempted, so such an approach can crack most passwords in a few seconds, for the cost of a few hundred dollars of graphics card. To defeat this, people started using slow hash functions for password hashing. The simplest way to make a slow hash is to take a fast hash, feed its output (and the salt) back into itself, and do that a few thousand more times; this is the basis of the PBKDF2 function, and it can slow down password brute-forcing attempts by a few orders of magnitude. Over time, more advanced password hashing algorithms have been developed, which resist not only GPUs but even customized chips (FPGAs or ASICs) designed to do nothing but brute-force passwords as fast as possible. No resistance is perfect, of course - the server still has to be able to hash your password when you log in, which puts a limit on how expensive the hash function can be made - but it can be literally millions of times slower to brute-force passwords protected by a proper password hashing algorithm (such as scrypt or argon2) than by a single-iteration fast hash (such as SHA-256). In other words, trying "the first few billion possible passwords" for each user goes from taking 1 second to taking a few weeks. Getting even a single password becomes expensive; breaking thousands of them becomes nigh-impossible.

Now, to answer your questions:

Is there any defense against this kind of attack?
Aside from what I mentioned above - use salt, use a slow hash function, and make it as expensive as possible to brute-force passwords - there's no way to truly prevent brute-force attacks. However, you can make brute-force attacks take so long to succeed that they are de facto impossible, if you can get your users to use passwords that the brute-forcing tool won't try within a reasonable timeframe. Simple permutations and common substitutions, like "password" to "Pa$sW0Rd", are easy for programs to try and therefore add little security, even though they'll get past the foolish "complexity" requirements many sites have. Using long passwords, generated with an element of genuine randomness, works much better. For example, a passphrase generation algorithm such as Diceware (online generator) can produce passphrases that aren't too hard to remember but are extremely strong. With reasonable length choices and generous estimates of cracking speed and technological progress, Diceware-style passphrases should be safe for at least a few decades (and potentially for centuries) even against an attacker who is doing nothing but try to crack that one passphrase using constantly-improving cutting-edge technology.

Does it help to increase the length of the encrypted keys?
Not really. Leaving aside that they aren't "encrypted" at all, the strength of a password hashing function has very little to do with the length of its digest. Obviously you should not use extremely short digests, because then you have a high risk of collisions (two unrelated passwords that hash to the same thing, and either one would be accepted for that user), but all secure hash algorithms have a digest of at least 128 bits, which is plenty to avoid that particular risk. Longer digests do technically make the comparison step of the brute-forcing attack take longer, but the difference is irrelevant next to the time it takes to compute a slow password hash in the first place.


What is the most used WiFi encryption? [WEP/WPA/WPA2]

WiGLE.net is a site where people upload information about WiFi access points they've discovered.  It's not complete, but it's a very large survey that should at least show you the trends you are interested in. This table is from their current stats page:

Wireless Encryption

WPA2: 171,834,316 (56.37%)
WPA: 23,980,785 (7.87%)
WEP: 29,492,258 (9.68%)
????: 60,103,751 (19.72%)
None: 19,818,038 (6.50%)


When testing out security vulnerabilities on sites such as OWASP Projects, should we be in a secured/protected environment?

There is a saying, and it goes like
Only the paranoid survives.
To answer your question, these kind of practice machines are built for the practice purpose by security enthu and experts who want to give something back to the society. By doing so the creator gets reputation and fame (sort of) in the Infosec family.
On the other hand, if you think about it the people practicing on these machines are mostly beginners with half the knowledge and can be a perfect target for such things. I mean look at the daily Infosec news like CISCO 0 Days, Xiomi's backdoors, exploits in linux systems such as overlayfs and many other examples will only inspire you to be as cautious as you can. Although no such news has ever surfaced, at-least not to my knowledge. But there is also first time for everything.
Again if one thinks about it, all such kind of projects are open-source and all their code and steps are available and easily visible. Also websites like Vulnhub who hosts the CTFs, always make sure these kind of things do not happen before they host any new user submitted machine. So as long as you are downloading your practice machine from a legit website you should be good to go. But again i can't argue with the urge to be more careful. Because no matter how careful you are, it's never enough, at-least not in the infosec field.


What's a trustworthy S/MIME Certificate Provider that generates my private key in my browser?

If you go to Comodo's page for the free S/MIME certificate, you may have a look at the "Subscriber agreement" which includes, in section 3.1, the following:

  The Subscriber's web browser will automatically generate a Private Key/Public Key pair during the signing up process.

So it seems that the process involves a locally generated key pair, as it should.

Trying out the process, I see the following:

A window from my browser briefly appears, talking about key pair generation.
An email is sent, saying that I may "collect" the certificate at a specific Web URL, with the collection password (included in the email). The email includes the sentence: "NOTE: We strongly recommend that you export your certificate to a safe place in case you need to reload it later."
If I try to collect the certificate with a different browser, that browser complains about the lack of a corresponding private key.
If I inspect the HTML source code of the collection page, I see a piece of JavaScript which includes a Base64-encoded PKCS#7 object (aka CMS), which includes my certificate but no private key (there is no standard for putting a private key in a PKCS#7 object).

So I can confidently claim that the private key was generated in my browser, not on Comodo's servers. The cross-browser test is the most definite here: if the private key was generated server-side, it would have worked. But all the other elements strongly hint at the same conclusion.


What's a practical example of how volatile information can be preserved in a digital forensics investigation?

Wouldn't I have to shut the system down (or reboot) in order to collect an image?

No, you can use a validated memory capture tool to collect the volatile evidence in RAM.

  If so, wouldn't I lose a large chunk of volatile information (e.g. running processes, memory, etc)?

Maybe, it's really hard to say. Research at Princeton University has shown that RAM fades rather than disappears. Cooling allows examiners more time to collect the volatile data. There are a few other concerns with pulling the plug:

Encryption. Powering off the machine could encrypt files that are unencrypted while the machine is running, meaning a loss of evidence.
Damaged data. Turning off the machine could render data unreadable.
Unrecorded evidence. Evidence may not be recorded unless the machine is properly shut down.

  From a practical perspective, how can volatile evidence be preserved?

You need to take a series of steps:

Once you begin, make sure you work uninterruptedly, otherwise you invite mistakes.
Gather your materials: report forms, pens, memory capture tools, etc.
If you need to press a key to wake the machine up, document it.
Note the date and time as it appears on the computer.
Record visible icons and running applications, and document running processes. This could help identify malware. You can access this information via the task manager.
Use a validated memory capture tool to collect the volatile evidence in RAM.
Properly shut down the machine to allow any running application a chance to write any artifacts to the desk, which will allow you to recover them later.

You can read more about this process in The Basics of Digital Forensics: The Primer for Getting Started in Digital Forensics by John Sammons.


Are any inherently insecure AES-CBC keys or key-IV combos known for properly generated random values?

A CSPRNG is expected to return every possible value of the image space with a probability indistinguishable from a random distribution.

Leaving certain results out would make a bad design. Think of dice. If you roll 1-1-1, you would not think that this is not random enough and sort it out - You just generated that entropy with certainty that it is real.

Doing so with an PRNG would compromise it's security, so no, there is nothing filtered out, hopefully.

Side note here: even if the probability is very small (so small as to be negligible): you are not supposed to reuse the same IV on the same key with AES-CBC, as to not leak anything if your files share structural information

Other than that, you should be fine with your approach. Every call to SecRandomCopyBytes you may consider a dice roll, for all you care about, as it's the best entropy you are going to get.

If your aim is not only confidentiality but also data integrity, you would be better off using another mode of operation as pointed out in the comments. I know, iOS is not very generous in giving much choice there, though.


Based on the URL being requested it seems that these are attempts to exploit a shellshock vulnerability in QNAP Network Attached Storage (NAS) devices. If this is not a QNAP NAS, and you know that your servers have the shellshock vulnerability patched, then you probably don't need to worry.

The fact that you are repeatedly getting requests for a URL that doesn't exist suggests that these attacks are not targeted toward you specifically, but are instead coming from automated bots that scan tons of online servers looking for ones that have a specific vulnerability. Unfortunately these bots are extremely common, so 100 requests a day isn't all that unusual for a small to medium sized website. It's all just a part of running a server on the Internet. As long as you are not vulnerable to the specific things they're looking for, they shouldn't cause a problem.


How are Ajax requests vulnerable to CSRF attacks if the Same-origin policy is applied?

The request can still be sent, just not read:

  Cross-origin writes are typically allowed. Examples are links, redirects and form sumissions [sic].
  Cross-origin reads are typically not allowed.

So only the reading of the response is protected by the Same Origin Policy, not the making of the request itself, although only certain headers can be used cross domain without CORS. For example, only the following headers are allowed:

  Accept
  Accept-Language
  Content-Language
  Last-Event-ID
  Content-Type

Others, such as X-Requested-With are not allowed so the presence of a custom header could be checked as validation that the request wasn't made cross domain or from a non-AJAX form.

Be aware that an old version of flash included a vulnerability that allowed headers to be set that would usually be restricted by the browser, and there was another vulnerability that allowed cross domain requests to be made without a valid crossdomain.xml to allow the request, so a token based approach may still be the most secure method of preventing CSRF.


From what I understand, unblocked-us is setup by pointing your computer to their DNS server. Their DNS server answers ALL DNS requests with their own servers, thus becoming a proxy/MITM.

E.g. you want to goto Youtube.com. This would resolve to 173.194.112.104
in a regular DNS server. However going through Unblocked-us DNS server
they would yield a different reply, their own IP address. This can be
illustrated better with the nslookup command:

nslookup netflix.com 8.8.8.8 (Google DNS)
Server:  google-public-dns-a.google.com
Address:  8.8.8.8
Non-authorative answer:
Name:    netflix.com
Address:  69.53.236.17

nslookup netflix.com 208.122.23.22 (Unblock-us)
Server:  UnKnown
Address:  208.122.23.22
Name:    netflix.com
Addresses:  173.208.170.14
      192.227.246.14
      204.12.200.14
      67.216.222.14
      172.245.210.14

This is absolutely dangerous. You are not only querying someone else's DNS server, you are actually proxying everything through their servers as well. Whether you want this or not is up for you to decide.


How should I report a security vulnerability?

Any domain has an abuse address. Try contacting them there. If you are uncertain of their reaction, use an "anonymous" mailing service through a VPN and/or proxy.


WPA2 Enterprise Authentication Certificate Security

Can the authentication cert on machine A be dumped out, installed on machine B and use to authenticate to the network?

technically, yes.

If machine A was a domain user, but has local admin privileges is the above scenario still possible?

I didn't get the first part: how machine can become a user?

Can I issue unique certificates to each machine for authentication or do they have to request one during the authentication process?

yes.


renegotiated master key in openssl s_client

Looks like this is not supported in s_client. However, the renegotiated keys can be printed by hijacking the SSL_read function in ssl/ssl_lib.c file of openssl library.

I added the following code to SSL_read().

int i;
printf("key is: ");
for(i=0;i<48;i++){
  printf("%.2X",s->session->master_key[i]);
}
printf("\n");

Then I ran apps/openssl s_client with LD_LIBRARY_PATH=. to print the keys used for each read operation.

Note: re-negotiated key based decryption is not supported in older versions of Wireshark. I used Wireshark-win64-2.3.0-3548-gc30bb2c


I suppose that by "sniffing" you mean "obtaining the cleartext traffic".

Basically, SSL/TLS has been designing specifically to ward off attackers who want to do that kind of sniffing. When organisations want to do it nonetheless, there are two main methods, that both break the SSL security model:

The sniffer may be configured with a copy of the server's private key. This is simple enough in practice (in particular, the sniffing apparatus can then be purely passive on the network), but it works only for a specific server whose private key is under control of the organisation. It won't work for arbitrary external servers (i.e. when employees do some Web browsing).

This method works for cipher suites using RSA, DH or ECDH. Crucially, it does not work for cipher suites using DHE or ECDHE. Pay attention! This is an important and often overlooked point: ECDH and ECDHE are not the same thing. Many people talk of "ECDH" when they actually mean "ECDHE". The reason why knowing the server's private key does not allow passing sniffing of connection with DHE/ECDHE is basically called forward secrecy.
The sniffer may do a full Man-in-the-Middle attack. In that model, the sniffer creates dynamically a fake certificate for the server that the client wishes to connect to. The client accepts that fake certificate because the corresponding root CA, which is entirely under the control of the sniffer, has been installed as a "trusted root" in the client system (this is where the SSL security model is bent: if you trust a CA that lies to you, then you're done for).

This kind of MitM is active and thus more invasive in network configurations, but it will work with arbitrary target servers, and also with all cipher suites (RSA, DH, ECDH, DHE, ECDHE...). Many vendors sell appliances that can do such things.

It shall be noted that this MitM system does not work with client certificates (but client certificates are quite rare in practice). More importantly, it is not hidden: users can notice that the certificate comes from a non-standard root CA.


How could I make the results of a yes/no vote inaccessible unless it's unanimous in the affirmative, without a trusted third party?

The theory
This could be implemented in several ways, by applying the principle of idempotency.
You want a system that only produces a result (binary 1) if all the inputs are active, that is, it tells you that everybody wants to leave the cult only if everybody has voted yes, otherwise the system must not return any kind of information (binary 0). This is basically an AND relationship between the inputs, as seen in the following table (0 = no/false, 1 = yes/true):
Input: You want to leave the cult.
Output: Everybody wants to leave the cult.

0 0 0 | 0
0 0 1 | 0
0 1 0 | 0
0 1 1 | 0
1 0 0 | 0
1 0 1 | 0
1 1 0 | 0
1 1 1 | 1 ---> hooray, everybody wants to leave, we can talk about it!

Now, that might not be trivial to implement safely, because you need something that can count (N-1 will not be enough to trigger the result, but N will), and something that is able to count might also be able to leak information about the number of votes. So let's forget about that, and realize that since you are actually dealing with single bits of information (either yes or no, 0 or 1), then you will be able to get valuable information if you just check the opposite (no instead of yes, 0 instead of 1, etc.). So if you check if they want to stay in the cult instead of leaving, and if you check if at least one person want to stay instead of checking if they all want to leave, you get the following truth table where all 1s have been replaced with 0s and vice versa:
Input: You want to stay in the cult.
Output: Somebody wants to stay.

1 1 1 | 1
1 1 0 | 1
1 0 1 | 1
1 0 0 | 1
0 1 1 | 1
0 1 0 | 1
0 0 1 | 1
0 0 0 | 0 ---> hooray, nobody wants to stay, we can talk about it!

Note that now we have an OR relationship between the inputs, which I believe is easier to implement safely, because you just need a system that respond to any input in the exact same way. Such a system would be idempotent: one vote is enough to trigger the output, and any subsequent votes would have no effect. Now, what can we use to implement such a system? The system would need the following features:

It must be trusted by everybody. It can't be built or bought by a single member of the family, or by someone else. So I suppose it must be something very simple that everybody can understand and trust. To avoid malicious manipulation of the system, it should also be operated while being supervised by all the members.
The voters must not be able to check the output before the experiment is over. This means that the vote must not return any feedback about the current state of the system. For example, blowing out a candle is not safe if you can see it, or feel the heat, or smell anything.

The system
The simplest solution I can think of is something involving an electronic device with an idempotent button, like a remote control to change the channel on a TV. Here's an example of how I would set up the system:

Get a device with an idempotent button. It might be a TV with a remote control, providing that changing to channel N always has the same effect no matter how many times you do it (idempotency). Or anything else you have at home, like a button to open a gate (if opening an open gate leaves it open), etc. The important thing though is that the system needs to be trusted by everybody, so if you really want to do everything safely the family might consider buying a new device (going to the mall, all together, and buying a trusted device).
Set up the system safely. All the family must be present while setting up the system, otherwise the system might be corrupted by the one who sets it up. In general, the whole family must be present and check all the operations from the beginning to the end of the experiment (like from buying the equipment to throwing it away safely).
Avoid any kind of feedback from the system while voting. For example, to change the TV channel, the TV and the remote could be under a huge thick blanket, and to vote you need to slide your hand under the blanket. But the volume should be muted, and maybe you'd better turn on some music in the background, loud enough to not be able to hear any possible buzz or noise from the TV. You might even want to define some delay between one vote and the next, to avoid getting any feedback from the possible heat of the remote control caused by the hand of the previous voter.
The voting process should be the same for everybody. During the experiment the other members must make sure the voter is not cheating (like peeping under the blanket, acting strange, etc.), so everybody is present during the experiment. There is a relatively fixed length of time that the voter should be able to stay with their hand under the blanket. Sliding it under the blanket and immediately pulling it out is not considered valid, since that would be an obvious and publicly distinguishable NO vote. From the outside, every vote must look pretty much the same.
Test the system before using it for the real experiment. You need to make sure everybody understand the process, votes correctly, and the system responds accordingly. The whole family takes part in several simulated votes for testing the system (simulated votes are fake and publicly known, not secret).
At the end, the system must be dismantled safely. Any buttons or parts that have been touched might need to be cleaned carefully, to remove fingerprints. If the family members don't trust the system after the vote, fearing that somebody might be able to extract information from it, all the parts of the system might need to be thrown away.

The vote
Supposing they have chosen to implement the TV-remote-blanket system, what happens is this. "Ok everybody, the TV is on, the current channel is 123. If you want to stay in the cult, change it to channel 0". Each member in turn slides a hand under the blanket and either changes the channel (if they want to stay in the cult), or pretends to change it (if the want to leave). At the end, the blanket is removed and... Channel 123! Then nobody wants to stay in the cult, hooray! ...or ...Channel 0! Then at least one member wants to stay in the cult! Or maybe all of them, there's no way to know.
Final notes
It was fun trying to think of a solution to this problem, but I consider this more of a thought experiment than a real security question. The problem is that the threat model is incomplete, because I don't think this scenario can actually make sense in a family where all the members are part of a cult. Cult members are brainwashed and paranoid by definition. They might not even trust a store to buy a new TV or a remote control, thinking anyone they don't already know (including any sellers) might be "enemies". It is definitely possible to set up a system without any electronic devices, using only simple objects like candles, pots, water, ropes, etc. That stuff might be easier to trust, compared to a black-boxed electronic device, but it might also be harder to make such systems work reliably. I'm also wondering: if a member of the family suggests that a vote is needed, isn't that suspicious? Why should a member of the cult want to know if everybody in the family wants to leave? Chances are the one who proposes this system is the one who wants to leave. Or this might all be a trap to find out who wants to leave.


Try Didier Stevens' PDF tools which should allow you to do this via CLI instead of GUI: https://blog.didierstevens.com/programs/pdf-tools/. Also, Didier did a lot of work on obfuscation methods so they should help you with most malformed situations.


How to sign and encrypt mail using openssl?

as suggested by dave_thompson_085,

I change

 cat ${content} |\

by

 $(file --mime-type ${content} | awk '{printf "Content-type: %s\n",$2} ' ; echo ; cat ${content} ) |\

and it work fine, I juste have to figure out how to send binary document, but that shouldn't be a problem.

thanks every one for help.


Symmetric encryption with different encryption and decryption keys

That encryption and decryption keys are not identical occurs in almost all symmetric encryption algorithm, from a certain point of view. For instance, if you consider DES, from the 56-bit key are computed 16 48-bit subkeys (through the key schedule). These 48-bit subkeys are what is used for encryption. So, it could be said that the actual DES key for encryption is a sequence of 384 bits (16×48). Then, if you consider decryption, the algorithm is identical except that the order of subkeys is reversed. In that sense, DES uses distinct keys for encryption and decryption.

This is not a very relevant concept. It has no implication on security. Symmetric encryption is called symmetric because the power to encrypt is equivalent to the power to decrypt: if you can encrypt then you know enough to decrypt the data as well. Even if the sequence of bits used at some point in the algorithm for encryption and the one for decryption are distinct, either can be recomputed efficiently from the other, so they represent the same knowledge.


How can you access a Facebook account if you know the access token?

What I find unclear is HOW they stole access token and what the video upload functionality has to do with it.

But that is not your question. You want to know how an access token provides access to the account of another user. This requires some knowledge on how a website authenticates you and gives you access. Session management explained here.

In a normal flow, you authenticate using a password, bio-metrics, etc. In exchange for a valid authentication, you receive a session id which is often stored in a cookie. For every other request, you add this session ID to prove that you are the same user as then one who authenticated successfully. An access token is basically a session identifier. It is provided to a user after successful authentication. The token can have a certain privilege level attached to it. This allows you to get a low privilege access token when using weak authentication such as password, or a high privilege access token when using stronger authentication such as bio-metrics. Probably, the view-as functionality provides you with an access token for a user other than yourself (the person you are viewing as). Due to some bug (unclear to me as well), this access token can be attached to other requests and result in a successful response.

Normal flow:

I authenticate.
I get an access token.
I fetch my profile and attach my access token as proof that I am the person who authenticated.
I receive my profile information.

Attack flow:
 1. I view as my target user.
 2. I somehow receive an access token for this target user.
 3. I fetch 'my profile' but use the access token of my target user.
 4. I receive the profile info of the target user.

The entire concept of tokens, SSO, session is more complex and I cut some corners. A session identifier often refers to a piece of information on the server which feeds access control with user attributes to base access control decisions on. An access token is often self contained, meaning it holds the user attributes possibly encrypted and signed.


Thankfully I am enormously competent with the Internet, and my incredibly extended experience made me aware of a very convenient, if somewhat confidential, service called Google. Interacting with this service for "UDIAuthToken" uncovered some pretty deep secrets, in particular that this parameter appears to be connected with a product called OMX from OrderMotion -- apparently a software platform for doing e-commerce. A parameter called "UDIAuthToken" is shown as part of some XML-based syntax in this document with this comment: <!---- Info. by OM --->

From this information, I infer that the "UDIAuthToken" parameter is a value which, from the API user's point of view (that's you), is quite opaque and is supposed to be provided "as is" by the software vendor. Thus, it probably encodes some license information. 160 hexadecimal characters means 80 bytes; with Base64 it would be 120 bytes. That's more than a simple hash; that's actually enough to do some serious cryptography, including encryption and signatures. IF this cryptography was done properly (an always risky bet, given the average competence of developers in the whole industry), THEN you would have a hard time forging a fake value for this parameter that the server would accept. After all, the point of licensing tokens is to remain under exclusive control of the software vendor.


Are there any known attacks (technical or social) against enterprises where password resets are scheduled on fixed (known) intervals?

The reason why recommendations for years is to stop passwords from expiring is to prevent people from doing what they normally do: mypasswordJune.
If you know that a large section of the user population is changing their password on June 1, then you can start creating password databases based on common patterns and adding:

summer
june
etc.

So the big threat here is credential stuffing.
Please inform the company about the recommendations to cease this practice.
The other issue will be load on the Help Desk systems. There is normally an increased number of calls when people need to reset. If there is a large block all changing their passwords at the same time, it then becomes easier for attackers to social engineer the Help Desk to gain access to an account:

Yeah, it's that time again. Look, I forgot to change it in time. Yeah,
I know. Can you reset it for me and tell me the password over the
phone? I'm not at a computer right now and I need that super-critical
email, etc. etc.

Because the call is "expected" the Help Desk's ability to suspect a problem is lower.


Governments may issue secret government subpoenas to communication providers that force them to disclose private data about their users or insert backdoors into their products.  Furthermore, governments may give criminal penalties to an organization that chooses to publicly disclose if a subpoena was issued.

Some tech organizations attempt to get around this by regularly issuing "we have never been issued any such government subpoenas" while signing their messages with their private key.  This message is called a warrant canary, with an analogy to a canary in a coal mine.  (If the mine begins to fill up with poisonous gases, the small canary will feel its effects before humans and serves as a warning to everyone to get out of the coal mine).  If the government issues a subpoena to them, they promise they will stop issuing the cryptographically signed message stating "we have never been issued any secret gov't subpoenas".  While the law allows the gov't to penalize them for disclosing information about a secret subpoena, there is (currently) no law that would require them to continue issuing such warrant canaries.

Granted, it's feasible for a gov't court to secretly force an organization to give up their private keys that were used to sign their warrant canary, or require them to continue publishing their warrant canaries or suffer severe consequences; whether this happens in practice is not publicly known.  It's also possible that the people issuing the warrant canary are not trustworthy people and would voluntarily continue to issue them, even while complying with government subpoenas.

For more information check out these links from the comments:

https://www.yalelawjournal.org/forum/warrant-canaries-and-disclosure-by-design
https://law.stackexchange.com/questions/268/what-is-the-legal-status-of-warrant-canaries


Accidentally typing part of password in username on secure website

If you submitted the login form (i.e., clicked "Login" button) then you should probably change the password as it could potentially show up in their webserver logs.

If you did not submit the form and simply typed it into the text box on the page, then deleted it (assuming no one was looking over your shoulder), you should be ok regarding the action as a whoops and move on.


Can someone explain what is TSource Engine Query?

I add to @schroeder answer. This is a common Distributed Reflective Denial of Service (DRDoS) attack. You can read about an analysis done on an number of games that are vulnerable to the attack.

  How to solve it?

Changing IP address is not going to help you as an attacker will easily find your new game server.

Read UDP-Based Amplification Attacks from US-Cert on two mitigations of DRDoS: Source verification and Traffic Shaping. You many need to setup an IPS (e.g. Suricata or Snort) on your game server to achieve this.

Alternatively, you can use DDoS protections services that are mainly paid solutions.


Can someone clone emv chip card by knowing the magnetic stripe info?

EMV chips can be cloned, but not with only the information present on the mag stripe. EMVs function as a challenge-response system, meaning an EMV authorization is transactionary between the ATM/POS and the card based on a secret stored on the EMV. There are three stages in this process:

Card Authentication - here the card authenticates itself to the ATM/POS
Cardholder Verification - here the cardholder authenticates via PIN or signature (the card is not involved in this step)
Transaction Authorization - where the transaction itself is done

Stages one and three present problems to our would-be skimmer. From the outset, the card has to authenticate itself to the machine. It does this by transmitting an RSA signature back to the machine over selected records.This signature is not going to be on the mag stripe. Once that's done, the transaction needs to be authorized. The ATM/POS sends the card the parameters to the transaction (amount, currency, date, etc.) to the card, which the card then returns signed with the secret, along with an ATC (a ticker that counts the transaction number) and an IAD (information specific to the card issuer). The ATM/POS sends this along to the bank for a green light for the transaction. By design, the secret isn't going to be stored on the stripe, and it would be impossible to store the ATC since that changes with each transaction.

Again, you could do a preplay attack on the chip, or you could take the chip apart and look at it under an electron microscope, but the magnetic stripe isn't going to be enough to mint new chips.


Should Google User ID's be hashed when stored in the database

If you hash the google ID you must then rely on the hash function having no collisions, also as you need to use a plain hash like SHA256  not a salted hash like Bcrypt2, because for lookups you need a hash that can be repeated with zero information. For passwords you want a salted hash like Bcrypt2 to prevent rainbow-table attacks.

Hashing the google id (and the email addresses) gives greater protection if your database is compromised, but it's only an option if you don't need that information while the user is logged out (when they are logged in you can remember what they used to log in). If you do need that information while they are logged out you can use reversable encryption or just store it in plaintext.


How can I safely use potentially infected USB sticks from a previous OS installation?

Depending on how paranoid you want to be, and how important the information on your computer is, you have several choices.

The most paranoid choice is to solder the USB contacts together and dip the whole thing in resin. Congratulations, your flash drive is now a perfectly usable paperweight and conversation piece.

The next option is to take the stick to a security professional. Hopefully your company's IT staff has a few who might be willing to help you out as a personal project.

If you have a disposable computer, you can boot it up using a live CD Linux installation. There are several available, and many exist specifically to scan potentially malicious files.  I would download updated malware definitions, disconnect the computer from the network, then insert the flash drive and scan its contents.  Then, once I'm certain the files are safe, reconnect to the network and copy the files over from the disposable computer, rather than inserting the flash drive into your Mac.

Since it's somewhat more likely that malware would attack generic USB flash drives themselves, rather than attempt to exploit a very specific bit of software that most people don't use, such as Preview on your Mac, I'd still be wary that the flash drive's firmware could be infected, and either discard it or turn it into a paperweight, after retrieving the files.  As for physical access to your flash drive? Just plugging it into an infected computer is enough to give the malware the physical access that it needs.


Well, remote diagnostics with a big portion of assumption on how your infrastructure looks like, would not produce results you can rely on, so I am writing in a more general-approach:

I would suggest, that you do some kind of investigation first to better understand the motive of the potential hacker. Did you for example check about the IP reputation of the IP source, i.e. with OTX (https://otx.alienvault.com/)?

Another option could be to put an IDS and WAF in front of your Online Service, as that would help to gain more insights. If that is too complex, the most simple way would be to at least record the packets to replay them / analyze them with i.e. Wireshark.

In terms of IDS / WAF, you could consider the following technology as they are not only industry standard, but also Open Source:

https://suricata-ids.org/

https://www.bro.org/

https://www.modsecurity.org/

Last but not least it is always a good idea to pentest your setup to have a better understanding about the potential risks there. OWASP Zed Attack Proxy is a good start:

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project


Why some applications host the API in a different domain?

Is there a security benefit to host the API in a different domain than
  the dashboard or marketing website?

In a word, resilience.

One benefit is that any security blocks which are put in place due to content on the dashboard or marketing website will not impact the API, if the API is on a completely different domain.

(If "marketing" means Wordpress or Drupal, for example, such blocks can be a very real threat!)

I've had direct experience with blocks triggered by the Google Blacklist, and they can impact the domain name and subdomains thereof.  If example.com ends up with malware on it, then api.example.com (and api.api.example.com) will get blocked as well.

Moving to api.exampleapi.com cleanly segregates the API so it won't be impacted if example.com is blacklisted.

  Why does a subdomain is not enough?

Again, with Google at least, blocks may extend into subdomains as well.  Also, DNS-based filters like OpenDNS wildcards will block all subdomains as well.


How to know what domains other clients visit if I have no access to the router?

Mayank Sharma advice is technically right but might not work in most of the environments because organizations/individuals use network switches nowadays which route data only to the intended recipient. Wireshark would work only where network hubs are used which broadcast the traffic to every node in the network.

In order to sniff traffic in switched environments you have to perform MITM (Man In The Midddle) through ARP poisoning. Once you perform MITM, you will be able to sniff data of the other nodes in a switch environment. I don't know if you are authorized to perform sniffing or MITM on the other machines so make sure you have prior approval.

In order to perform MITM you can use many open and closed source tools. Cain and Abel and Ettercap are two tools that are very easy to perform MITM. Cain and Abel is only for Windows platform while Ethercap works fine on both Windows and Linux.


The role of Machine Learning In Cybersecurity Defense

Machine learning technology is certainly better in scope compared to signature based systems. To your example about SQLi attacks, signatures could look for specific commands/strings within the HTTP payload as means for detection. ML based approach can, instead, define the behavior as process spawned on the db server or unwanted read-only operations etc etc. If there is another novel SQLi attack which escapes the signature (string did not match) but the consequential behavior remains same (process spawned or unwanted read-only operations), then ML approach will come out flying.

Having said that, the ML based approach can only detect a behavior it is trained for. In the above example, if the SQLi attack results in a new reverse tunnel opened to another host, but we did not train the model for this behavior, then the ML approach will not succeed either.

(Answer to the previous question on how signature systems differ from ML based systems)

Yes. Signature checks only for a specific vulnerability and multiple vulnerabilities at best. Machine learning, however, focuses on the behavior of the attack which does not necessarily mean how the exploit was handled, but rather post infection activity etc.

Aside: Developing ML based security systems is my daytime job.


Password management for kids - what's a good way to start?

Maybe the lesson for children should be less about how to use tools to manage a password, and more about understanding why managing passwords is important?

Let them write their passwords in a notebook. Have fun with devising a method for obfuscation in case the notebook is lost. Teach them about backups- keeping a copy someplace safe. In my experience, kids and old people are a lot alike when it comes to password (mis)management

Until they were skilled enough to manage their own password database, I also kept the kids logins in a "family KeePass". This is the same one where the aged family members stuff is- because people die and sometimes you need to recover things for otherwise unable people. The trust/risk calculus is different in a family group than in a work or social circle. There is also a difference between sharing access to a password and sharing a password.

It is awesome that you are thinking about this early. Good luck!


Is it possible to embed information that is both nearly invisible to the naked eye and decodable from an external camera?

Consider that you might not want what you are asking for. That is, if the purpose of watermarking is to prove that you authored it, your cuttingroom clips and outtakes are evidence enough - you can provide them, your violators cannot.

This does suggest a possible approach for the second use of watermarking, which is to identify who leaked the video.

This approach is frame removal. If you remove a tenth of a second here and there, it will not typically be noticed by those without access to your original footage. But it will be picked up by a camera.

Say in low-action scenes you remove a block of every 5th frame for half a second, and call that a "one"; or you don't remove them, and call that a zero. Your lead-in will be a string of ones, then a zero, then the ID, read right to left.

So say you read, in the recorded film, 111010110000....
then the 1110 is the lead-in, and the id is 00001101, or 0x0D. This is the 13th copy you gave out.

Synch the audio by cutting it, speeding it up, etc as appropriate.

The more frames you remove, the bigger the effect. Initially it will only be noticeable with a comparison against your original.

Another way to do this kind of timing-hack is just to remove N frames before/after each cut, or even insert extra darkness frames during fade-cuts. But that only lets you add/remove a few frames per cut, which reduces the number of bits of data you can store.

===

@Mindwin pointed out a fatal flaw in this idea.

Any unique watermarking system is vulnerable to comparison between two copies, in which case you can detect the watermarking.

But with my proposal above, given two copies, an attacker knowing the system can change it to a third id, either by removing additional frames, or by XORing or frame-duplicating to replace frames! Not good.

I thought perhaps by adding frames as well as removing them, that this could be resolved. But I can find no solution that would be proof against a determined and well-informed attacker (if I assume the algorithm is public, and that they have at least two watermarked copies).

I consider this a fatal flaw: no watermarking system should allow an attacker to frame another user as the leaker.


Are there standard protocols for user authentication over JWT?

Great question, and probably one that doesn't have a satisfying answer.

The JWT format is specified in rfc7519, but as far as I know it's kinda like HTTP: the standard headers are defined, but how you use them in your app is up to you.

For example, should your JWT contain only an expiry date, a sessionID, and a signature? Maybe that's ok if you have a strong server-side session mechanism. But if you're totally stateless then you probably need to carry more data in the JWT. Should it contain a userID? Should it contain group or access control info? Should it include info about how the user logged in - which portal, or which authentication method? Is any of this info sensitive enough that the the JWT should be encrypted so that the user can't see it? Is your web app designed such that all services that consume the JWT are able to share an AES private key to decrypt it?

TL;DR: I'm not aware of any RFCs or frameworks that tell you exactly what data should be carried in your JWT, but I'm also not sure this is really possible since the questions around what data you need to carry in the JWT depend heavily on the architecture of your app.


How many people would need to answer a survey of 1000 questions before the aggregate data from the survey is sufficiently anonymous?

You're asking what is the number n of survey respondents such that n is higher than the threshold for anonymity. I feel like this is putting the cart before the horse. To answer questions about how many responses you would need for it to be anonymous requires knowledge of the population, which is the entire point of a survey. That leads us to...
A concept called k-anonymity. It's not strictly what you're asking for. But k-anonymity looks at the existing data and determines strategies for altering it to provide anonymity. In theory, this would work on whatever size data set you end with. The caveat being that the suppression and generalization operations required could render the data less useful.


Why do websites show parts of phone numbers, but never email addresses?

This is all based upon the design of the website.

E-mail address is commonly used for username for your account. So, if the website exposed few characters from the e-mail address then it's few less characters to brute force. If the website does not use e-mail for account name then it's narrows down attack for social engineer or other forms of attacks.

Phone number is not commonly used for the username, so exposing this doesn't have an direct threat towards compromising an account on the website.


As discussed on the original version on stackoverflow:

It all comes down to who you trust. Some organisations will trust government, while some definitely won't. Some will trust a bank in this role, but would a competitor trust them? I have seen many banks set up their own PKIs or use a PKI vendor - and the physical security requirements around root CA generation and storage are very James Bond!

For your specific situation, look at your needs, trust requirements and risk. What PKI provider is most likely to match your needs? How is their disaster recovery and business coninuity plan structured - does this match your requirements? How do they prevent compromise of the root CA?


Can a security job be cracked without OSCP?

I am a penetration tester; I got my job without an OSCP but I was studying for it. That, however, was not relevant.

I emailed every single CREST (UK) company I could (CREST provides a list, but I only got 1/4 of the way down the list before I got interviews), no generic emails.

I explained my situation, my interests and my goals.

My tips for you:

do as many CTFs as possible; hackthebox is a good CTF. You may have high interest and some background but you need to show and talk about that interest.
email all the small companies, applying for a big company probably will not get you anywhere
make all of those emails personal and attach your C.V. (make sure your C.V. is security focused and clean)

The little guy is always willing to invest in the little guy.


How realistic is it to spoof a specific UDP IP address?

An important thing to note here is that you are not strictly connected to a server with UDP in the same way as TCP, as UDP involves no handshake process. That said, there could be some sort of handshake included into the server's own logic.

As suggested by commenters in this question some ISPs, switches and routing devices do feature source checking so while it is definitely theoretically possible, your actual mileage may vary.


How can a seamless cloud storage service be Zero-knowledge?

The service can create a random encryption key on the client and then encrypt that key with your password, the service will never have access to your plain-text password.