In light of the glibc DNS vulnerability, why aren't Linux distros updating install images?

Maintaining a distribution is Hard Work.  It takes a lot of logistics to test the software packages,upgrade them, communicate with downstream developers, etc.

The install disk is the first experience a user has with the software, and it simply has to work. If it doesn't, the user isn't installing the software.  So that's why distributions only make point releases and upgrade the install software every so often.  If you had to rebuild the software at every security update, you'd be doing that so often you'd likely have quality control issues far more often that would be acceptable.

I'd say you're correct that the software would be vulnerable on first install.  This is a tradoff the distribution maintainers have (likely) weighed and accepted.  Upon install, generally the first thing that happens is updating the software.  There's some small risk that during this period, someone might be able to take advantage of the glibc vulnerability.  The only DNS lookups that would happen before the glibc vulnerability was patched would be mirror sites, so an attacker would either have to control this, or perform a MiTM attack.


How can I find if my password has been posted online?

Probably the most comprehensive database of searchable compromised accounts is haveibeenpwned.com.

If you've reused the password in multiple places then yes you should assume that password has been compromised. I also recommend enabling two-factor authentication wherever possible as this will reduce the risk of one account being compromised leading to other accounts being compromised.


Is Double NAT a secure way to create a public wifi network?

You've got it hooked up backwards if you want to secure your network against guests.  Computers on the 192.168.0.0/24 network can freely access computers on the 192.168.1.0/24 network.

If you want to use double-NAT to create a guest network, you need to place the guest network closer to the Internet connection than the network you want to protect from them.  Against casual attackers, NAT acts as a firewall with a "default deny" policy for inbound connections and "default permit" for outbound connections, so you need to put the computers you want to protect on the "inside" of the second NAT.

Against serious attackers, you want your public and private networks to meet only at your Internet connection, where you set up a proper firewall that blocks any communication between the two.


As it can be seen on the link that you shared:
https://www.exploit-db.com/exploits/30235
The vulnerability can directly exploited with simple GET requests therefore elaborated exploits are not required.
There is a RCE on /room/get.php and you need to replicate the following steps in order to create a file called shell.php that will be your web shell:

Create the file called shell.php. This file will execute the command assigned on the "cmd" GET variable :

http://127.0.0.1/KikChat/rooms/get.php?name=shell.php&ROOM=<?php system($_GET['cmd']); ?>

Access the file and get command execution using the "cmd" get variable:

http://127.0.0.1/KikChat/myroom/shell.php?cmd=whoami;
There is also a LFI on the /KikChat/private.php page on the name parameter:
http://127.0.0.1/KikChat/private.php?name=../../../../../../../../../../boot.ini


The specific problem with your code is that you don't actually escape anything and allow user-defined HTML code at multiple places.

This is the code you create:

$2

The values $1 and $2 are user-controlled and both need to be filtered (in different ways).

For $1 you need to make sure that it's not possible for an attacker to escape from the attribute by supplying double quotes ("). One way to achieve this is using htmlspecialchars(). Another problem (which you tried to address) is that links can start with pseudo-protocols such as javascript:. Therefore you should also whitelist a few plausible URI schemes. A restrictive but safe method would be to limit the input to URLs starting with http[s]://.
For $2 you need to disallow any HTML tags. Again, a quick-and-dirty solution would be applying htmlspecialchars(). But note that this can cause problems if you plan to support nested BB tags.

The general problem is that regular expressions are not the right way to process nested markup, especially not for security purposes. It's very easy to mess this up. Try to rely on the tools of your framework or use libraries such as HTMLPurifier. You should also look at some basic guides on preventing XSS.


non-rfc1918 address appeared on router dashboard

The IP you provided is owned by A.C. Nielsen, which is most famous for providing television ratings based on sampling by recording devices.  They've since branched out into many other forms of market research.  The most likely reason you're seeing it is that some device on your network or some page you browsed to triggered activity data to be sent to them.

I would consider this activity innocuous - albeit, if you're the kind of person who is performing deep packet inspection on their segregated-from-the-roommates LAN, no activity is innocuous.  But it's Marketing spying on you, not Government or Hackers.


Can a secret, S, be efficiently recovered from a list of usernames and SHA256(S + username)s?

No. This would require a first-order preimage attack against SHA256.

However, for cases where you wish to key a hash, HMAC constructions are a better choice.


Resend encrypted REST GET request to eavesdrop data

Alice's replay request will fail on TLS level because TLS is immune against replay attacks (e.g. look here).

And even if it wasn't: Why the hell would Alice be able to decrypt the response from the server? It would be encrypted by the TLS session key. Just replaying something doesn't give you access to the session key...


Microsoft is suggesting that you do both.

This is a part of their PowerShell v5 paradigm known as JIT/JEA (or JitJea) aka Just In Time, Just Enough Administration.


LastPass installer scary message about sideloading

There's no more risk installing LastPass by sideloading than there is installing/running any other executable that you download. And since LastPass is well-known and trustworthy, it's basically no risk at all. Microsoft is intentionally making it sound much more dangerous than it is in an attempt to strong-arm everyone into their store.


Is it possible to escalate privileges and escaping from a Docker container?

A user on a Docker host who has access to the docker group or privileges to sudo docker commands is effectively root (as you can do things like use docker to run a privilieged container or mount the root filesystem inside a container), which is why it's very important to control that right.

Breaking out of a Docker container to the host is a different game and will be more or less difficult depending on a number of factors.  Possible vectors include :-

Kernel vulnerabilities.  Containers running on a host share the same kernel as the host, so if there's an exploitable issue in the kernel that may be used to break out of the container to the host
Bad configuration.  If a container that you have access to is running with --privileged you're likely to be able to get access to the underlying host.
Mounted filesystems.  If a container you have mounts a host filesystem, you can likely change items in that filesystem which could allow you to esclate privileges to the host.
Mounted Docker socket.  A relatively common (and dangerous) practice in Docker containers is to mount the docker socket inside a container, to allow the container to understand the state of the docker daemon.  This allows a trivial breakout to the host.  More information here

If you're looking for more information I'd recommend these whitepapers from NCC.  Abusing Privileged and Unprivileged Linux Containers and Understanding and Hardening Linix Containers . There's also a presentation I did which covers some of this stuff here.

If you're interested in Docker hardening I'd also recommend having a look at the CIS Security standard.


customizable (open-source) wifi hotspot software?

One would not go wrong with CoovaChilli. CoovaChilli is an open-source software access controller, based on the popular, but now defunct, ChilliSpot project. CoovaChilli works on Linux operating system and probably other *NIX systems too. I have not tested other operating systems.

CoovaChilli allows you to flexible authentication using Radius server, allowing you to customize authentication and fallback mechanisms. As you are planning to run on a laptop, you can comfortably use FreeRadius as Radius server.

CoovaChilli can be easily integrated with third party user management solution.

Checkout http://coova.github.io/CoovaChilli/

Also checkout, http://coova.github.io/CoovaChilli/chilli_query(1).html explaining you how one can integrate the CoovaChilli with your software.

Disclaimer: I am not promoting the CoovaChilli with any commercial motive. I have no commercial relationship with developers of CoovaChilli


If I am trying to clean install a MacOS with internet recovery, is it safer to use mobile network than WIFI network?

However, since my Pc was had a virus, I was worried that my IP
  addresss and home WiFi network has been compromised,

I suggest you to reset your WiFi, try to check the authenticity of firmware cross-checking hash(if present) in the admin panel to the documentation provided with the product to ensure installation of wifi firmware is not tampered and then update the firmware later, change all your default WiFi password (admin login and WPA2) to complex long custom ones. Make use of mac address whitelisting on wireless router and allow only limited number of users on it. It will be added benefit if you consider educating yourself on how in general evil twin works or other general techniques to avoid giving up your secure password.

  can I still trust that the installation was not tempered with?

I am pretty sure that the installation of MAC is done after establishing secure connection to system. MAC OS is not easy to play around on the fly. Tampering should be difficult if not impossible on the connection which is established from WiFi to machine. Installation is susceptible to corruption and can break easily.

  should I perhaps reinstall it again using mobile network? Since I have heard that mobile data are much more secure than WiFi network.

Please check if the installation is clean and free from the virus detected earlier or any virus in general. This should suffice to ensure safe environment to operate and continue using current installation


Will disabling the Java add-on in IE protect you from Java exploits?

My German is pretty rusty, but I'm pretty sure the article from Heise Security doesn't really say what the H-online article claims.

  Unter Opera erreicht man die Plugin-Verwaltung durch die Eingabe von opera:plugins in die Adressleiste. Beim Internet Explorer genügt das Deaktiveren der Plug-ins unter "Add-Ons verwalten" nicht. Wer den IE einsetzt, sollte Java daher besser vollständig über Systemsteuerung/Software deinstallieren.

Which roughly translates to

  The plugin manager for Opera can be accessed by typing opera:plugins in the address bar. For Internet Explorer, it is not sufficient to use "Manage Add-ons" for deactivation of Java plug-ins. Anyone that uses IE should completely uninstall Java via Control Panel / Programs.

IE doesn't allow you to completely disable the Java plugin from within the browser. Instead, you have to use a registry key to disable it properly. The article from Heise is hinting at this - simply turning off the plugin doesn't actually fully disable the embedded Java functionality in IE. I believe the Heise article writer was unaware of this registry trick, and that the H-online article writer just took the advice "as writ", without properly checking the facts.

So no, you don't need to uninstall it completely. Though I would certainly put it at the top of your list of stuff to uninstall if you can survive without it, considering the tirade of recent 0-days.


Does the ability for a user to choose the value of a session id cookie constitute a security flaw?

Yes there's a risk as this is a classic session fixation issue (OWASP Page).  Standard good practice for web application session management would always be to re-issue a random session token whenever the user submits a login.  Anything else (either not re-issuing on login or allowing user set session token values) is not a good idea.

How much of an issue this is depends on exactly how the application works and the user environment.  Some examples of this being a risk

A lot of web sites have unauthenticated ares which are not encrypted.  so if the token is set on these and then not re-isued, the token can be hijacked by a packet sniffing attack (e.g. over a wireless network) before the user logs in and then the authenticated session can be hijacked
If the application is accessed from a shared PC environment then an attacker who can set the value of the token in an open browser, would be able to hijack a users session if they use the system without closing and re-opening the browser (assuming that the token is deleted when the browser is closed).


How do I diagram a network node with multiple layers of trust?

You may want to look into EFF's diagram of comparison between Tor and HTTPS for some inspiration: https://www.eff.org/pages/tor-and-https

Note the actual diagram in the EFF site is interactive, which is neat but not strictly necessary as you can illustrate the same using multiple images as well.

The basic idea is that you need to identify each piece of information that has different security domains and label which domain are privy to which piece of information.


Can I check that a plain SSL private key corresponds to an encrypted SSL private key without decrypting it?

Given that you use the openssl rsa command, I will assume that you refer to RSA private key files in the PEM format, encrypted using AES256. These look like:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,87FD3191BA64A020594BD81962FB092A

pqS/qSsKxhodfAafiqFyx4opaMo4HsQ9c97gT1YgI3DmZBN1w/8mlAPn8YAe98j6
...
/IlNA3RyQdHY1JIcHsnZ0HWW13kGQ1pzofhNbHQkOWimrKupKMmhPKSSMx6Q+lCm
-----END RSA PRIVATE KEY-----

Unfortunately for you, all the base64-encoded data here is encrypted (emphasis mine):

  The line beginning with Proc-Type contains the version and the
  protection on the encapsulated data. The line beginning DEK-Info
  contains two comma separated values: the encryption algorithm name as
  used by EVP_get_cipherbyname() and an initialization vector used by
  the cipher encoded as a set of hexadecimal digits. After those two
  lines is the base64-encoded encrypted data.

So it is impossible to obtain the original private RSA key without decrypting it.

Your configuration script must find other ways to detect that a RSA private key file has been updated (for example, by comparing timestamps, reading some markers, etc, etc.).

Since you mentioned SSL, note that certificates are bound to a RSA private key. In that case you can extract the public key from the RSA private key and certificate using:

openssl rsa -in server.key -noout -modulus
openssl x509 -in server.crt -noout -modulus


Detecting and filtering data over AC power lines?

The simple answer is that you can't. Power lines are physical cables that interconnect machines in your office, as well as between offices. It's just not possible to identify the use of these kinds of communications without resorting to measuring noise on those lines, or (as Lucas said) buying a bunch of hardware that uses those communications technologies and hooking them up. Even then, you're going to have problems of cross-talk and interference, and a user could probably just unplug them from the socket when you're not looking. It's not feasible in the slightest.

If you want to prevent someone from using one of these ethernet-over-power technologies to communicate with sensitive equipment, install a UPS on that equipment that has conditioned output. These UPS units take an incoming AC power source, regulate it to DC via a switch-mode power supply (SMPS) and then use a large power transistor (e.g. FET or IGBT) to "step" the output power, either directly (by driving a 50/60Hz signal) or indirectly (charge pump into a capacitor). Part of this usually involves a feedback step, which allows very precise changes in output voltage to be made in order to maintain a perfect signal. The main reason for doing this is that load (i.e. the amount of current being pulled by devices on the UPS) will often alter the performance of the UPS, especially when load spikes occur. The feedback allows the UPS to maintain phase and voltage at all times. The overall process entirely removes any noise from the input supply, and makes the use of power-communications technologies nearly impossible on that circuit.

The fact is, though, that a determined person will always find a way. They could use WiFi, Bluetooth, XBee, ethernet cables, USB drives, FireWire, etc. to defeat any kind of air-gap you have installed. You need to prioritise your protection to sensitive areas, and mandate strong security practices elsewhere via policy.


can XSS attacks be nullified by prepending a backward slash to all external links?

No, this is not enough.

An attacker does not necessarily need to call an external script. They can dump the payload directly into the inline script too. Depending on the length restrictions in place, this can become quite tricky, but still manageable.

The main takeaway from this is that custom-made solutions are not very secure. Every now and then I see people trying to ask if their new ingenious solution just stopped all XSS, CSRF, SQL Injections, etc...

The answer to all of these questions is no. XSS Protection is a problem that has been solved already, with proper output encoding and additionally possible input validation.

This means that every output needs to be encoded for its intended destination. Don't do this yourself either, but use a framework or library which provides this for you.

Input validation verifies if input is in the expected format. For example, if you expect an email address, RFC-822 offers a very large regex, which is guaranteed to validate all standard-conform email addresses. Is this overkill and unnecessary? Probably. But for simpler things like numbers, you can implement input validation in addition to output encoding:

if (input.matches("^(0|[1-9]\d*)$"))
{
    // "input" is a valid integer
    return true;
}
else
{
    // "input" is not a valid integer
    return false;
}

This example code would allow all integers without zero-prefixes. Any other input will be rejected.

Summary

Never use your own custom method to implement security! This is the golden rule of security and breaking it will get you hacked.
Use output encoding for the target context! If untrusted data is written into the DOM, then encode it for the DOM. If it's written for an attribute value, then encode it as attribute value. Encoding is the only way to be sure.
Optionally use input validation alongside output encoding! By ensuring that input is what you expect it to be, you can save yourself multiple headaches down the line.


If on the server side we use a REGEX...

You should use a whitelist, not a blacklist. Use a regex to match only letters, numbers, and a couple symbols. It's easier and safer than trying to solve every single way the attackers could inject scripts.

  Since this would not send any data back to server, how does this pose a threat?

A script CAN send data to the server. Imagine the following snippet:

Nothing

You point the mouse to the B tag, and all your cookies are sent away.

  Using firebug we can inject scripts almost everywhere.

Firebug is a debugger, running in the client side, operated by the client. Anything done within Firebug does not count as an attack, because is a user-initiated action. If you convince the client to open Firebug and execute any procedure, you probably could ask him to download an executable, put it on the antivirus whitelist and run it with administrator privileges.


Is it safe to store public key encrypted password in the Mobile Device for authentication purposes?

You should look into token-based authentication. That is, tokens issued by an identity provider - not to be confused with security tokens that are generally used with multifactor authentication systems.

This authentication method eliminates the need to store a password in every client, yet provides the convenience of not having to prompt for credentials on every application start. This works by storing the access token on the client, which is presented to the server on every request and expires after a certain amount of time (e.g. 7 days).

This approach is similar to cookie-based authentication (like used with WS-Federation), with the important difference that it isn't prone to Cross-site request forgery (CSRF) attacks.

I highly recommend researching the OAuth standard.


You have confused the PHT transformation with the PHT layers of the block cipher's round function:

The PHT transformation maps a two-byte input to a two-byte output.  It uses the formula you listed.  For instance, PHT(0,1) = (1,1).
The PHT layers of the round function map a 8-byte input to a 8-byte output.  Each round has a sequence of 3 layers.  Each layer consists of 4 parallel PHT transformations.

The input/output vector you list is for the PHT layers of the round function, not for the PHT transformation itself.  If you follow the computation diagram (see, e.g., Figure 7.12 and Section 7.7.1 in the appropriate chapter of the Handbook on Applied Cryptography, you will see how the PHT layers transform the input (0,0,0,0,0,0,0,1) to (1,1,1,1,1,1,1,1) by application of 12 PHT transformations in the appropriate sequence.

One last comment: I do not recommend using SAFER K-64.  It is an outdated cipher.  There are a number of shortcomings: there are some minor cryptanalytic weaknesses in it; it has not been studied very much; and worse, the key size and block size are too small.  For these reasons, I do not recommend that you use SAFER K-64 or that you expose it as an option to your users.  Instead, I recommend that you use AES.


My suggestion is to ping that address and check the TTL value and with tcpdump verify the path that the ICMP packets takes, over tap0 or eth0 according your configuration, if you get the ICMP destination unreachable is because your router can not find the address. As other users suggest you can use traceroute and verify the path, but with your setup probably with pings you will make it work.


Do certain SSL certificates / certificate authorities load faster than others?

First, check not only the time needed for TLS but also time needed for initial connection. If the initial connection is already slower than for the other sites then the TLS handshake will be slower too - simply because the site is worse reachable from you in terms of round-trip latency.
If only TLS is slower than it is more likely that it might be caused by a bad key exchange method - which is independent of the certificate but dependent on the server configuration. RSA is the fastest key exchange but bad in terms of security. ECDHE is fast enough and recommend. But with a bad server configuration it might use DHE which is terribly slow. Also the speed of the key exchange depends on the performance of the CPU and the amount of resources available for computation: if the system is on its limits the key exchange can be significantly slower.
A major speed improvement in the TLS handshake comes also from session reuse, at least up to TLS 1.2. Thus the difference might also be caused by other sites doing session reuse and yours not.
There might be problems with TCP flow control if the certificate and chain is too large, i.e. if RSA 4096 is used (RSA 2048 is sufficient), many SAN are configured in the certificate, many intermediate certificates are sent and maybe needlessly the root CA certificate too. Optimal would be to use ECDSA certificates instead since they are smaller, but they might not be supported by all clients.
In case the client does a certificate revocation check using OCSP this might additionally slow down the handshake. Unless OCSP stapling is used by your server and supported by the client, the client needs to contact the OCSP responder of the CA to check if the certificate was revoked, which costs additional time.

EDIT after the target website is known:
A detailed timing shows that the TCP connection to the target website and the TLS handshake take about the same time. This is expected since the site is using TLS 1.3, i.e. TLS itself is already pretty optimized (apart from the useless inclusion of the root CA, i.e. "Contains anchor" in the report from SSLLabs).
Compared to servers like google.com the site is much slower though. This is because Google has data centers world wide and their location and routing is optimized to have a fast connection to the customer with small latency. A simple ping already shows the difference in round-trip time, which for the site in question are several factors larger than for google.com.
In other words: this is not a TLS or CA problem, but the target site simply has a worse network connection than the other sites the OP is comparing too.


SVG-Snippets in Access-Log: Probe or Error?

It looks like a CSS script (check out the Referrer field) might contain an inline SVG.

This kind of inlining is not supported by all browsers, though. So where a modern Firefox might see

src="data:image/svg+xml;base64..."

and display an image (or a SVG), an older browser would "believe" this to be a file name. So it appends the name to the base directory it was using, and blithely requests that filename. Which earns it a 404 instead of a cigar.

If this is the case, you either ignore the fact, or could use a Rewrite to answer with a remediation SVG to these malformed requests (it might be awkward if there's more than one SVG in the same virtual path - but you could use a SVG crafted to display 'Upgrade your browser!'), or modify the CSS, if you have access to it, to use a (slower) off-line SVG inclusion instead of the current online one.

Update

Apparently, this used to happen a lot with users of old browser which also installed some "browse enhancing" widget. The widget was probably injecting some JS/CSS in the page, and the result wasn't always correctly interpreted by the browser. Rendering a gradient background in SVG and embed it as a base64 string was a trick used for IE9.

So, I'm convinced that it's nothing you should worry about -- there is a problem somewhere but it definitely seems to be not your problem.


You can have some serious fun playing with printers, photocopiers and other such devices - even UPSes. Security is usually an afterthought at best, if not totally absent.

Stuff I've seen:

Default credentials used everywhere, and web-based config panels storing passwords in plain-text, often within a generated config file. I've never seen anything better than plain MD5 on passwords, and in one case I saw CRC32.
Document names and usernames leaked via SNMP, usually via open read access to the device and over SNMPv1/2 where no transport security is used.
Default or hilariously weak SNMP private namespace names (usually "private", "SNMP" or the manufacturer name), allowing you to reconfigure TCP/IP settings, inject entries into the routing table, etc. remotely, and there are often ways to alter settings that can't be set in the control panel. It's pretty trivial to soft-brick the device.
UPnP enabled on the device in default setup, allowing for more remote configuration fun. Often you can print test pages, hard-reset the device, reset web-panel credentials, etc. Again it's usually possible to modify TCP/IP settings and other networking properties.
Very outdated 2.2.x and 2.4.x kernels, often with lots of nice root privilege escalation holes.
Badly written firmware upgrade scripts on the system, allowing you to flash arbitrary firmware to internal microcontrollers. You could use this to brick the device, or install a rootkit if you're willing to spend a lot of time developing it.
Custom or old SMB daemons, often vulnerable to RCE. Easy to pwn remotely.
Services running as root, user groups set up incorrectly, file permissions improperly set.
Printing jobs ran asynchronously by executing shell scripts, making it easy to escalate your privileges up to that of the daemon (often root).
Poorly written FTP servers built into the device. I'd bet good money that a fuzzer could crash most of those FTP daemons.
All of the usual webapp fails, but especially file upload vulnerabilities.

Here's where things get extra fun. Once you've pwned the printer, you can usually get hold of usernames and other juicy information from SMB handshakes. You'll also often find that the password to the printer's web control panel is re-used for other network credentials.

At the end of the day, though, the printer is an internal machine on the network. This means that you can use it to tunnel attacks to other machines on the network. On several occasions I've managed to get gcc and nmap onto a photocopier, which I then used as a base of operations.

What's the solution? First, you need to recognize that printers and photocopiers are usually fully-fledged computers, often running embedded Linux on an ARM processor. Second, you need to lock them down:

Update the firmware of the device to the latest version.
Firewall the printer off from the internet. This should be obvious, but it's often missed. TCP/IP-based printers / photocopiers usually bind to 0.0.0.0, so they can quite easily sneak onto the WAN.
If you can make the printer listen only to traffic from the LAN, do so.
Change the default credentials on the web control panel. Again, obvious, but still not done very often.
Find any services running on the device and attempt to break into them yourself. Once you're in, change passwords and turn off what's unnecessary.
Get yourself an SNMP discovery tool and dig around what's available for your printer. SNMP has a bit of a learning curve, but it's worth taking a look.
If you do internal network monitoring, set up a rule to watch for anything unusual coming out of the printer. This cuts false positives right down and gives you a good indication of when something dodgy is happening.

All in all, if it's a device plugged into your network it is probably pwnable, and should be part of your risk management.


USB stick encryption on specific network/domain

What is common is just the opposite: only allow secure removable storage media on a network, while you want to disallow your secure USB stick outside of the network.

The only way I can imagine, is to encrypt the USB stick and manage to make the key only accessible from the local network. The simplest way would be to use a HSM to store the private key that is used to decrypt the symetric key used for the USB stick encryption. Unfortunately, that will not prevent a malicious user the store the decoded symetric key and later use it outside of the network.

As it makes harder to use the USB stick outside the network, it may (or not) meet you actual requirements. The hard part is that to increase security further, you would need a special USB driver that securely connects to the central point that decodes the symetric key and never let it accessible to the user. It may not be that hard to develop if you can use a normal USB driver as original source, but driver development is risky because a buggy driver can easily make a machine no longer useable, and I have never heard of such a driver. I'm sorry no to be able to give your more than a hint, but I cannot imagine a better way...


Is it acceptable for customer service to ask for my PIN?

Your action is justified from me. I have never been asked from any major and respectful company such information, neither for a service, nor even for account recovery. Send a message to the official support team and see if these info are actually needed if this thing causes you lots of inconvenience. But be aware of this - you might be scammed.


What is happening now with the Grub backspace key security vulnerability?

The main thing that is happening is that the bug is being seriously overhyped.

Exploiting this vulnerability requires physical access to the computer during startup, and if you've got physical access, there are about a zillion ways you can bypass security.
The bug is about bypassing Grub2's internal password protection.  Most users don't password-protect Grub2.
The bug is in the Grub2 bootloader.  If you're using direct boot from UEFI, LILO, classic Grub, or any of the non-x86 bootloaders, you're not vulnerable to it.

If you're worried about this bug, install your distro's patch for it, but keep in mind that, except in unusual circumstances, the vulnerability doesn't actually reduce security.


What's the difference between Systems security and Information Security?

System security : how easy is to break into a system and compromise it, thus having access to the information behind it (access from both inside or outside). Remember that on a system most things can be accessed by root/Administrator.
Information security: how do we best keep our information? Is it safe from disaster (geo distribution)/hardware failure(backups, raid, snapshots, etc)/ hackers(public exposure)/unintended uses (access policy)?
From this perspective, system security is just one aspect of the many that you have to account for when you talk about information security.


Large lan party : How to identify the users on the network?

Why match IP to username? Why not simply match MAC address to their ID? Then it doesn't matter what the IP address is.

The only issue is whether they will/can spoof their MAC address, although, if you are in a wired environment, you can set MAC filters on the switches since you know the MAC addresses, and alerts on MAC table flooding.

All this is assuming they are all on the same network for this party and not going through routers.


Short answer: No

Complementing what schroeder said, you can verify the content of that QR code with any QR code scanner (there are some for PCs). I verified and the content is an URL, like:

https://login.weixin.qq.com/l/YYEwfl9Y-A==

By itself those qrcodes are not dangerous for your mobile. However, whatever is in that site is what you need to care of. Some sites may have exploits that could potentially access data in your mobile (specially if your browser/os is not updated or old).

If you check the content of a QRcode and looks like Javascript code, then I would be worried about, however in order that to happen, the QRcode itself would have to have a lot of information in it (making it hard to pack in a "common" size QR code).

So your next question should be: is "wechat.com" safe? If you downloaded their app, you should also ask if that app is safe. That app has much more potential to access your data (depending on what permissions you allowed it), which in that case, if they wanted to steal your data, they don't need the QRcode for that, they already have the app in your phone.


Password Free WiFi, but page is using https - am I secure then?

If your premises are correct, yes, you are protected, in that the password will be sent encrypted to the remote site.

But...

Are your premises correct? Is that really a free WiFi offered by the airport?

It happened to me twice - once in Schiphol Airport, once on a train bound for Rome - that I found an "open free WiFi" near me. The one on the train (those trains are called FrecciaRossa, 'Red Arrow') was even called 'Freccia Rossa Free WiFi'.

Except that they were honeynets, set up by some creep and employing man-in-the-middle strategies to be able to decrypt your HTTPS connection. With some browsers, and some plugins, you are warned. Most of the time, you are not, or you're induced to disregard some low-level threat warnings ("Those dialog boxes pop up all the time, just click OK already!").

This kind of trick can be performed with devices already configured that can be bought on the Internet (just google for 'pineapple wifi', and that is one example), so it's not like you need to enter the Matrix to get pwn3d this way.

Also, on WiFis that do not offer "client isolation", several attacks are possible that just might allow both sniffing your connection and hijacking it. And you're at risk of your device being hacked, too. Some Android phones had a vulnerability that could be exploited from their local network, but a WiFi AP without client isolation is indeed your local network. Much less likely than being pineappled, because few phones are likely to be hackable, and even then, there's not much that can be profitably done to them in a short time. Of course, if you always go to the same bar, who's to say that nobody is after you specifically? How interesting a target are you?

With a passworded WiFi, at least you have to get the password from someone "official", who is unlikely to be able to say "I wasn't aware" or "it wasn't me!" when the police comes by to investigate your bank account having been drained.

Even so, check carefully what network you're connecting to and pay attention to browser warnings. It's not too difficult to go to the bar, ask their SSID and a password, then set up a different, way more powerful AP with the same SSID and password, and start reaping accounts, identities, possibly some big money every now and then. Also, once you have the SSID and password, try navigating to the router's administration page. If you can, that's a very bad sign; customer APs ought to be only reachable from a wired connection (and not the WAN, either. Not from any random IP at least). If the AP is insecurely administered, or worse yet, vulnerable to some exploit, there again safety flies out of the window.

So: actually, no. You are not automatically safe.


How to backup my new laptop after I caught a hacker/identity theft in action without losing all of the evidence when I erase to factory default

Magic-sudo's idea of making a 1:1 copy of the hard drive is good and basically feasible - this is what a digital forensic analyst would probably do as a first step in order not to mess with the actual laptop. You can achieve this with a Linux live USB stick and the 'dd' command. The next thing he'd do is calculate the fingerprint of both the original laptop HD and the copy, to prove that they're identical.

BUT - if you then reset your laptop to factory default, YOU'VE LOST YOUR PRIMARY EVIDENCE. Digital forensic analysts go through all this trouble of copying the device data so they don't need to touch the actual evidence, which could corrupt the evidence otherwise. they need the original to remain untainted so any evidence they find can be independently verified by other analysts if necessary. If you wipe your laptop, you still have a digital copy of the hard drive, but it will be impossible to prove that this is a copy of the state your laptop hard drive was in right before you factory-reset everything if you don't get some kind of legal certification that it is, before you factory-reset. It might even be impossible to prove that the copy you made came from your laptop at all. Basically, you break the chain of evidence if you do anything else than turn your laptop over to the police as Terry suggests.

So you'll have to decide what's more important: Have a chance to bring your identity thief to justice (which will probably be very difficult, but depending on what evidence is on your laptop hard drive, it might be possible), or get back the use of your laptop immediately. If you turn it over to the police, you should probably forget about getting it back anytime soon.


veil framework, reverse https and tcp payload differences

There are multiple benefits using https:

More likely that firewalls will accept this traffic, rather than a random port.
HTTPS encryption hides what is beeing sent over the network, so IDS/IPS systems will not see what is going on - given that there is no SSL termination (transparent).
HTTPS will look more normal in firewall logs. It is not unexpected as connections to random ports.


I clicked on a grabify link. What can someone do with my IP?

An IP address is simply like having your home address on a letter. They can know the area where you live but not more.
A malicious user could try to hack your network but usually, home routers are pretty safe and will prevent any intrusion by default (if you haven’t modified port forwarding and settings like that).
Anyway, random people online are already scanning every IP in the world and already tried to hack in anyone’s home, without success most of the time, and as every website you visite potentially logs your IP already, you shouldn’t be less safe. Pay attention to phishing emails you could receive showing you your IP address as a mean to gain your trust (if the sender tries to impersonate your ISP for instance).
Don’t panic, stay safe.


Signal: contact people, or have people contact me, without revealing phone number?

The addresses in Signal is the phone number. It's specifically designed to use the phone number to address message, to be a drop in replacement for SMS, and offer opportunistic encryption for text messages and calls between phones.

If this is not fine in your situation, then Signal is (sadly) the wrong system for you. As you say, Telegram (and many others) allow you to use a chosen username.


Wildcard SSL Cert and Client Authentication

Client authentication in SSL is not correlated with whatever is in the server's certificate. That the server certificate is wildcard or not has no bearing on whether client authentication will be used or not.

Client certificates will be used only if the server asks for them. Then, the server must be able to validate the certificate (make sure that the certificate is genuine, and comes more or less directly from a trusted root), and then to extract a notion of identity from what is in the certificate. In the IIS / Active Directory world, this is called mapping. See this page for some details.


What does "if the Crypto Officer performs this operation" mean in this BitLocker security policy?

The FIPS 140 standard defines a number of technical terms (§2.1). Beyond that, you can assume common English meanings for words that aren't defined in the security policy you're reading.

The word operation is not defined in the standard, so it has its ordinary English meaning: “the act or process of operating” (Webster) (oh, and operate means “to produce, as an effect; to cause”). The operation here is the release of keys for storing on a USB flash drive.

Releasing a key from the cryptographic module means copying a key from inside the module to the outside of the module. Since Bitlocker is a software module, “inside” means that you need to go through Bitlocker to access it and “outside” means that you don't.

What the sentence means is that only the crypto officer can cause Bitlocker to release keys. Crypto officer is defined by FIPS 140-2; it is the role of the person(s) who can manage the keys stored in the module. This is usually the administrator role, the most privileged role possible on a cryptographic module. If the cryptographic module is a physical box with secret material inside, the crypto officer is the guy with the keys to the box; other users can only act on the box in controlled ways from the outside.

Bitlocker is intended to keep keys confidential. This sentence says that only the crypto officer can break this confidentiality. Usually, keys are extracted from a security module to back them up or to migrate them to another security module.


Why is RFC4255 (SSHFP) not used for https?

There is a RFC for that. It is part of what DNSSEC is meant to do.

Now don't get too hopeful about "top dollar" or reduction thereof. The need to "certify" in some way public keys with regards to server names is not magically removed by switching to DNSSEC. The "CA" role is just moved around, and the associated costs are still there. It can be predicted that if the registrars must assume these costs, then their prices will rise. Sooner or later, someone will have to pay for it, and I have a strong suspicion that it will be the SSL server owner.

Philosophically, it is unclear whether merging the certification structure (the PKI) and the naming structure (the DNS) is a good idea. The merge would sure simplify the communications between DNS and PKI when dealing with the specific case of issuing certificates bound to host names; but it also means that the two responsibilities become intertwined. It takes a substantial dose of wishful thinking to believe that whoever is a good registrar would also be a good CA; the two kinds of activities are vaguely similar, but not identical.

Also, certificates are supposed to have a scope beyond HTTPS servers; they should be usable in contexts which have no relation whatsoever with the DNS and host names, for instance when signing software (application, drivers...).

Economically, it would not change much. Among the commercial CA, the most used is VeriSign, aka Symantec. Switching to DNSSEC means that the ultimate certification authority will no longer be VeriSign, but whoever manages most of the root DNS, i.e... VeriSign. Now THAT would be change, wouldn't it ?

Politically, there would be trouble with "state CA". Many of the dozens of CA which are trusted by default by a Windows system are "vanity CA" sponsored or even operated by various governments. The same governments have no intention to operate DNS-related infrastructures which require a lot more bandwidth and availability; and they would resent seeing their precioouuusss certificates becoming "second-class citizens".

For security, this is mostly a non-issue. Fake certificate events are very rare; we hear about one such occurrence per year. The bulk of Internet-related frauds and phishing and other attacks does not rely on fooling existing CA. In other words, the current CA system works. Don't fix that which is not broken. Yeah, the CA system looks brittle and prone to failures, but despite much publicity about the occasional breaches, the raw fact is that it survives.

Summary: the standards are ready, the RFC are published, the software is written. Now all that lacks is a reason to switch from a "commercial CA X.509" world to a "commercial registrar DNSSEC" world. It is hard to see what good it would actually do.


Is there any flaw in my API-to-API authentication concept I missed?

The main flaw of this concept is that it is totally pointless.

Essentially, what it does is:

Requester: Hi, I am going to tell you my random name I just created just for you. Here its hash. [step 2]
Receiver: Haha OK, here is your hash back [step 3]
Requester: Let me check [step 4]. Cool, the hash you returned indeed belongs to my random name for you. I let you see it now and I will forget it immediately [step 4,5]
Receiver: Hey, your name indeed produces the hash you provided earlier. Cool! [step 6] I now finally know your name! [step 7]. Let's get down to business. How can I help?

You claim that

  This is an authentication only method

whilst the flow inherently only attempts to make sure that the Requester remains the same throughout the communication — something that HTTPS itself already takes care of.

The point of authentication is to verify that whoever claims they are are indeed that party. This implies that the Receiver either already knows the party (e.g. has its password hash or public key in its database to check against) or is able to verify against trusted third party (e.g. using OAuth). In your scenario, the Receiver does not know the Requester at all, and the fact that it merely tells its name does not authenticate it in any way.


It doesn't matter that you have the identity unless you are a trusted idp for the service that's protecting its resource with SAML. That said, if you have a SAML response from an idp that the service trusts, then you should be able to post that to them as an sso token.


Windows System event log warnings for smtpsvc

It means that whatever service is connecting to your SMTP server attempted to send an email to a domain it couldn't deliver to. This is fairly normal stuff for an SMTP server, assuming you use it to send messages to users in various domains.

You can turn on logging and see what's failing: http://support.microsoft.com/kb/303738


Possible security measures to put into place before allowing screen sharing

For best security, you can use a screen sharing program that does not give the auditor control over mouse and keyboard. You can talk with them over the phone/VoIP/video chat and have them instruct your staff on what to do. Make sure the staff is properly briefed to know what can be disclosed to the auditor and what requires further authorizations (e.g. data that contains personally identifiable information).

Some video chat software has screen sharing component, e.g. Google Hangout, Skype.


It's impossible to say in your specific situation. What I can say is that there's basically an arms race between the author of jailbreak detection libraries and people creating apps to hide jailbreaks. Apps like xCon attempt to beat the detection libraries. Google "hiding jailbreak iOS 8" (or appropriate version).


Can subdomains of trusted domains be registered for malicious use?

Two separate items come to mind here: Hijacking of existing subdomains and creation of new subdomains. (I'll skip the obvious third item: take over an existing subdomain's host.)
The links in this question refer to hijacking abandoned subdomains: an attacker can take advantage of an existing subdomain that was defined as a CNAME to another domain that was available for registration. Simply register that other domain and accept mail for the CNAME and you can gain an SSL certificate. Your rogue host will work until the domain owner yanks the CNAME.
Creating a legitimate domain's subdomains can be done by hijacking its DNS (e.g. phishing their GoDaddy credentials). This is known as domain shadowing:

Domain shadowing is the process of gathering domain account credentials in order to silently create subdomains pointed at malicious servers without tipping off the actual owner.

This technique is most commonly used to compromise small less-tech-savvy sites since the site admins aren't likely to notice (they'd have to log into their registrar and notice a new subdomain is present). It's not at all likely to come from a domain like microsoft.com, which is big enough to have an information security team protecting it.


Convert raw memory dump into a format recognized by volatility

By default, LiveKD acquires a kernel memory dump that appears as a crash dump file, not a complete raw dump of the contents of RAM. Volatility requires a complete memory dump. I recommend any of these tools for Windows memory imaging. The goal of LiveKD is for debugging, not forensic analysis (KD = kernel debugging). It's an alternative to having to use WinDbg and KD via a serial connection to debug the kernel 'live' (and the system doesn't have to be booted in debug mode). LiveKD fools the debuggers into thinking that they are looking at a crash dump file by implementing a file system filter driver that presents a 'virtual' crash dump file that debuggers can open.

With that said, the dump from LiveKD technically may contain a complete dump of RAM if the correct options were given to it but with a header preceding it so that debuggers recognize the file format as a crash dump file. A crash dump file is simply a file header followed by the contents of physical memory, so that the driver can satisfy reads of the virtual dump file with the contents of physical memory, which the driver can easily read from the \Device\Physical Memory section object the memory manager creates.

In the book The Art of Memory Forensics written by the creators of Volatility, they discuss the structure of Windows crash dumps on pp. 96-98, explaining that "the Windows crash dump file format was designed for debugging purposes" and that they begin with either a _DMP_HEADER or _DMP_HEADER64 structure (p. 96). The authors clarify that only complete memory dumps are compatible with Volatility, not kernel memory dumps nor small dumps (here is a MS TechNet blog entry that explains the difference).

I personally use the 010 Hex Editor for many forensic parsing tasks involving binary data, and it has a pre-made template for parsing 32-bit crash dumps. See the Volatility documentation for further information about the crash dump header formats.


How to back up and restore personal data safely from possibly exploited android phone?

Great question. Sorry to hear about your phone. If your phone still functions, you can back up to cloud. Google Drive being one highly integrated options. Just save your files to your cloud (I'd create a separate folder so you can clearly see if any malicious looking files end up there somehow, unlikely but worth looking). Then do a OS reset and wipe the SD.

This phone also has a wifi-direct option so you could use that to transfer files.
https://www.verizonwireless.com/support/knowledge-base-210398/

If you can't make those happen, and assuming you are correct that the USB backup options is dumping malware... really the only option left is manually wiring into the storage on the phone and that is pretty next level hardware stuff. I'd say worse case take the full back up to usb, then sort through for your files and delete the rest. Be careful to make sure you do the backup to a computer you can "wipe" if needed or infected (not likely as different OS, but I'd be careful).


Is there some OSS toolchain for disallowing execution of all unsigned binaries on linux?

Integrity Measurement Architecture gives you that. See
https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture#Using_digital_signatures_for_immutable_files
It is mostly useless if you keep a powerful interpreter on the system, but a shell wouldn't necessarily qualify (no direct syscalls for example). So it can be a very good tool to exploit proof a locked down system.


Exploit/DoS applications with a 0 width and 0 height image

These type of bugs cause DOS attacks when the image parser or the renderer fails to parse the image. However, its not that only 0x0 or 1x1 images can invoke such situations. Say, a normal file which targets a certain parameter from the parser can lead to similar attacks. its all how the software is processing the image file.

Check this one out:
Cool PDF Image Stream - Buffer Overflow (Metasploit)
The Above vulnerability triggers due to a malformed image file. A good example for your research and yes, these attacks are not theoretical


Both the use/restriction of special characters in passwords is related to improving different aspects of security.

When a site requires you to use passwords with certain minimum length or include atleast one numeric character, special character and so on. They want to force the user to create a strong password that is less susceptible to brute force attacks (i.e.. 12345 is not gonna fly).

Similarly, restricting certain characters/length can be considered a (weak) defense mechanism against attacks like SQL injection. Although keep in mind that front end restrictions can be easily bypassed by an attacker. In addition, websites may place restriction on certain character (like whitespaces) depending on how they parse/process passowrds.
In general, limiting passwords is in itself not a good idea.


What can be done against DDoS attacks when I just have only small number of "known" clients reaching a server?

I would whitelist in the Firewall the known IPs (it can be done in minutes if you already have the IPs even if they are 1000). That would make sure anything else trying to connect will be automatically rejected.

In a CISCO firewall this certainly would work fine. An ASA if with a Content Security and Control Security Service module then you may enable signatures as well to mitigate DOS/DDOS/SYN-FLOOD.

Additionally, in the case of a Linux machine, you could just enable fail2ban and get rid of anything unwanted.

In the good case scenario, your server is behind a Firewall and you put filters on both the firewall and server machine.


Will 1.1.1.1 hide my traffic from my landlord's router?

The sources you cite in your question suggest that you are confusing two different services offered by Cloudflare in the context of 1.1.1.1:

there is the traditional offer, which consists only of a DNS server available directly or with DNS over HTTP (DoH) or DNS over TLS (DoT).
and there is Cloudflare Warp, which is practically a VPN

With Cloudflare Warp all traffic is protected against sniffing by the landlord since all traffic between your system and Cloudflare is encrypted. See this answer for details.
With Cloudflare DNS instead there is much less protection. While the landlord can no longer get the contents of the DNS if encrypted DNS is used (i.e. DoT or DoH),  the landlord can still extract sensitive information from other traffic. For example plain HTTP traffic is not protected at all. But even with HTTPS the target hostname can be extracted from the traffic in most cases. And the landlord can also see the IP addresses you connect to and deduce from this what sites you visit. The landlord might also do selective blocking of sites or services based on this visibility. With Cloudflare Warp instead none of this is visible to the landlord and no selective blocking is possible.


Design a machine image that is capable of running a virtual server inside of it. Your domain image is there to provide security and monitoring. Primarily, it is needed to keep anything sufficiently ugly from flowing OUT of your honeypot. Also, packet captures!

Stick the honeypot inside it, and you can turn them on and off at your heart's content.

Legal issues? At the base of it, you have taken reasonable steps to prevent your machine from doing damage, but somebody beat you on it. I know of no cases where somebody is found liable for an infected machine before. If you're particularly concerned beyond that, I offer the following two options:

Get a lawyer.
Get a gift card with cash and use TOR.


Is it common to be audited for security, but not be given access to the audit results?

Indeed, the situation you describe does not lend itself to speedy resolution of any vulnerabilities found by the mega corp audit. However, beware that may not be the point. Even if the real purpose of the audit is to fix security flaws, there are some reasons that the mega corp can't share specifics.

What other purposes does a security audit have other than fixing security holes? Well, read your contract and think through everyone's motivations. As others have said there may be contractual or political motivations. Off the top of my head:

Mega Corp may want to break or renegotiate your contract, or a contract with someone else. They're using the audit as leverage.
Mega Corp is doing a risk assessment of their product, and they just want to understand what kind of risk your software poses to their business.
Mega Corp is following a rule or regulation that says they need to make regular audits and that's all they've decided to do.
Mega Corp doesn't want to start a paper trail that documents potentially damaging vulnerabilities, or they don't want the paper trail to leave their physical control.
They might be legally prohibited from (or legally concerned about) sharing information from a classified/controlled environment to an unclassified/uncontrolled environment.

They might feel they have legitimate security reasons for not sharing specific vulnerabilities as well.

They might not trust your company and giving you a list of specific test cases will tell you a lot about what kinds of issues they've had in the past, as well as issues they predict to be problems for them in the future.
They might not want you to just fix whatever bugs they found but instead do a more comprehensive review. If they tell you they can slip strings X, Y, and Z through your input validation then you'll be tempted to just fix those specific cases. If they just tell you that your input validation is a piece of crap and to fix it or else you'll lose your contract then your company is going to take a really careful look at the whole software from top to bottom.


Issue #1: sec_error_ocsp_server_error can occur for other reasons than OCSP server internal error.
From Bugzilla bug 495380:

SEC_ERROR_OCSP_SERVER_ERROR is used 5 times in ocsp.c for everything from an internal OCSP server error to failing create the request session and any number of different problems writing the request to the remote server.`

Issue #2: I believe that Firefox is caching this error but should not do so, so I created Bugzilla bug report 1014979.
Workarounds (from a post that I wrote at another forum):

Method #1: Restart Firefox.
Method #2: Go to Options->Advanced->Certificates-> Validation. Set checkbox "When an OCSP server connection fails, treat the certificate as invalid" to the opposite of what it is now, and then press OK button twice. That is sufficient to clear the OCSP cache. However, since you probably want the original setting that you just changed, go to Options->Advanced->Certificates-> Validation and set checkbox "When an OCSP server connection fails, treat the certificate as invalid" back to the value that was there before you read this post, then press OK button twice.


What measures must be taken to securely authenticate from web traffic to a WebSocket connection?

The WebSocket TLS (WSS) connection is a different connection from the HTTP TLS connection.

A WebSocket connection is created sending a HTTP request containing the wish to upgrade the connection to WebSocket and by receiving a HTTP response granting this wish. From then on the WebSocket protocol is spoken inside the upgraded HTTP connection.

This means that the common security properties of HTTP are still usable with WS, i.e.  things like basic authentication or verifying the identity of the peer against a session cookie given by a previous login.

It also means that the security properties of TLS can be used as with normal HTTPS connections. Like HTTPS, which is HTTP spoken inside a TLS connection, WSS is WS inside a TLS connection. This also means that preventing man-in-the-middle attacks by validating the certificates is done exactly the same way as with HTTPS, because every WSS connections starts as HTTPS connection.

If I understand you right you consider that Mallory manages a man-in-the-middle attack against the connection at least once. If Mallory is able to do this he must be able to man-in-the-middle the TLS connection and in this case game over is anyway, no matter if WebSockets are used or not. If Mallory is instead gaining the information from a non-TLS connection (i.e. HTTP not HTTPS) than you have a design bug in your application if you use unprotected authorization data for authorization inside secured connections, no matter if HTTPS or WSS. And no TLS or other methods can make compromised authorization information magically safe to use again.


I think it would be very difficult to truly understand security concepts like XSS and SQLi without knowing at least a little about the underlying languages.  While you may be able to execute a XSS or SQLi attack without knowing javascript or SQL, it would make you more of a script kiddy than it would a true security expert.

It also truly limits your ability to find vulnerabilities that are a little off the beaten path.  The deeper your understanding of how a language works the easier it will be for you to exploit applications that use it.

That being said, knowing a little about a language will go a long way.  You don't need to be a SQL master to understand how SQLi works.  Just being familiar with the basics will help you familiarize yourself with concepts like SQLi.


Is there a difference between "DHE_PSK" and "PSK_DHE"?

It's a mistake. See Errata 3987 for this RFC:

  Section 4 says:

         CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM_8 = {0xC0,0xAA}
         CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM_8 = {0xC0,0xAB}

  It should say:

         CipherSuite TLS_DHE_PSK_WITH_AES_128_CCM_8 = {0xC0,0xAA}
         CipherSuite TLS_DHE_PSK_WITH_AES_256_CCM_8 = {0xC0,0xAB}


opentsa.org used to develop mod_tsa, in 2006. The site is dead as of 2013. I don't think anyone uses RFC 3161.

See https://web.archive.org/web/20120114151658/http://opentsa.org/


The system doesn't really have a name. But several aspects of it do:

An "air gap" is where two devices intentionally isolated such that they can't touch, and that terminology is also used in security to describe carefully maintaining one system or network physically disconnected from another.

As far as using some storage device to transfer data between two machines, we used to call that "sneakernet"; a bit of a tongue-in-cheek reference to using humans to form the critical link ferrying data on foot between machines, though the term is less popular than it used to be (probably because the concept is less popular than it used to be).


Why does Yahoo cached results button lead to blacklisted "malicious"/"phishing" IP?

I don't think yahoo has been comprised. Not that I would expect them to tell us if they discover they were!

I agree with the https everywhere scenario. Plus it could be that the IP is marked by these services as phishing because

It's and IP rather than domain name
on this IP is returning 'fake' copies of sites. Which is correct as they are cached but this might trigger some phishing protection services
the lack of HTTPS could also influence the above possibly


A) Yes, they do keep track of purchases. Almost all prepaid gift cards require some form of registration where they collect different data about you: name, address, zip code, phone number, etc.

B) It will. The gift card becomes an account, and you can review your purchase history just like a regular credit card.

However, you can be a liar when you activate the card, and put in fake information. You can go to a store reasonably far away, or to a very busy store (my local pharmacy is always stuffed). You can also pay with cash, which means you don't have records from a credit card company to link your identity with. And, if you're smart with your purchases (don't attempt to order drugs to your house) they can't get any information from the merchant.

tl;dr: If you have cash, you avoid most of the tracking. If you lie to the company, it's very easy to dodge identification.


How effective is Caja at preventing XSS?

In my opinion that totally depends if you are just using Caja, or whether you have got a backend language as well.

The reason I say that is because you could have something like a search module on the backend which doesn't sanitize any data, thus a malicious well-formed string could be output, causing an XSS (or other attacks).

If you are talking about how effective is Caja at preventing XSS from it's side, then from what I've read, it looks quite good, but I have never personally used it, however I hear good things from it.


Do we use different CAPTCHAs with different difficulty to how sensitive the request is?

After many years of working in the information security industry, I have yet to come across such an implementation. This doesn't mean it can't be suitable for certain use cases, but it definitely isn't an established design pattern.

I have seen a decrease in the usage of CAPTCHAs during the last years, because UX experts hate them. CAPTCHAs are mostly used as last resort (e.g. after 10 failed login attempts) or implementations that aim at less UX impact (e.g. reCAPTCHA V2) are used.

But there is another mechanism known in the security world, that might fit your need. It is called step-up authentication. This pattern basically forces a user to re-authenticate with the same or a stronger form of authentication, before he can perform a high-risk task. This achieves what you are looking for: It verifies that the visitor knows what he's doing.

A good examples for this approach is deleting a repository at GitHub. Before you can do this, you must re-enter your password and type out the name of the repository, which you selected for deletion. That way the user is forced to stop and think again, before making a crucial mistake by deleting the wrong repository.

Another example are critical operations which require MFA before they allow execution. You may be able to log into your online banking account with username and password to check your balance, but if you want to perform a transaction, you must enter an additional PIN sent via SMS as a second factor.

You have to evaluate, if a ramp-up authentication would solve your problem in a more elegant way are you really do require CAPTCHAs. Please take into account, that CAPTCHAs are usually not considered user friendly and may have an impact on your customer satisfaction.


hydra -l admin -P /root/Desktop/wordlists/test.txt dvwa http-get-form "/dvwa/vulnerabilities/brute/index.php:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect."


How can Remote Code Execution in Unity infect me?

A tough question to answer. While it's always safer to just update since a patch is available from the vendor + updating shouldn't be too much of a burden since it's just you working on your project. But nevertheless, let me try to lay out the facts.

There's no publicly available exploit - it doesn't look like the researcher or the vendor has provided much information regarding exploiting this vulnerability. All I could find was that there is an input string validation that leads to RCE. Know that the lack of an availabile exploit does reduce chances of exploits being found in the wild.
While I did not find any CVSS on the vendor's website, the NVD CVSS does indicate that this vulnerability can be exploited remotely. If this is true, then I assume that even if you are working alone, but connected to the internet, this vulnerability may be exploitable, hard to tell for sure without knowing the vulnerable component and how it works. That said, NVD CVSS is not 100% trustable in my opinion, but still a point to note when analyzing.
This is a rather old vulnerability and being an RCE, honestly, I'd just recommend patching up. The vendor did promise to release more information about it once they gave their customers time to update but still haven't (the vulnerability received a CVE in 2017). On the plus side, a tweet from the vulnerability finder did mention that they fixed it very quickly (kudos!). Alternatively, they have also released a mitigation tool for those versions that don't have a direct patch. Note - according to the vnedor, the mitigation tool is not a permanent solution and just disables the vulnerable component (check if this component is remotely accessible!).

Again, I'm just stating what's already known. When it comes to patching, other than any heavy effort/downtime, I would not weigh anything against updating (especially for security). If you're working standalone and it's easy to update, I would always advocate patching up :)


How can I ensure my dll has not been modified?

For Windows binaries, I would suggest to digitally sign the file.

Where you use certificates, almost the same technology of HTTPS.

Introduction to Code Signing

SignTool

Then you should use Windows cryptographic APIs to verify the signature of loaded DLLs.

I know that to get this done, you need lot of work.
But, for Windows, this is the safest path. If SHA hashes are not enough, this is the alternative.


Preventing phishing of few critical websites

A common phishing website looks extremely similar to the website it is trying to impersonate, but is still a different website.

One could develop a tool which examines any websites the user visits and alerts them when they look exactly identical to one of the websites is set $S$.

Unfortunately there is a problem with this: A phishing website only needs to be almost identical. Comparing data for exact equality is trivial for computer programs, but detecting almost equality  is a far more difficult problem. The tool would require a complex heuristic algorithm to rate the similarity of two website. Such algorithms could be gamed: It would be easy for the phisher make subtle changes which are invisible to the user but causes the program to mistake it for an unrelated website.

There is, however, also the opposite approach which is far easier: Notify the user when the website they visit is legitimate and do nothing on illegitimate websites. This is already built into most modern web browsers in form of certificate notification icons in the navigation bar. This mechanism requires https to be used, so it won't work when you regularly use the http version of said websites. Training users to only enter login credentials when they see the green lock-icon with the name of the website in the address bar (extended certificate) is very reasonable.

The browser plugin HTTPS Everywhere by the Electronic Frontier Foundation automatically redirects the user to the https version of many popular websites. It is highly recommendable for security-conscious internet users (and even more recommendable for those who are not).


Doing a dictionary attack on RSA if you have the public key?

RSA encryption, as per the standard, mandates the use of a padding method which includes random bytes, precisely to avoid the problem you describe. This makes RSA encryption non-deterministic (encrypt the same message twice with the same key, and you won't get the same output; but decryption removes the padding and recovers the message, of course).


Why is Home --> VPN --> Tor worse than Home --> Tor?

Preface: I consider this question to be a false dichotomy and an inversion of the burden of proof. One of the core tenets of building secure systems is that you minimise the attack surface, and resist additional components and features wherever possible to keep in line with this. As such, if one cannot identify a strong reason to include a component in the system, and quantify that reason against the threat model, the additional component should not be included. This question is worded in a way that assumes that the VPN provides some benefit, and that removing it is what should be questioned, when in fact the inverse is true: the correct question should be whether adding a VPN layer to Tor provides any tangible benefit. Only when such a benefit has been affirmed should we entertain including it.

What follows is my original answer to the question before I added this preface.

This depends on your threat model, local laws, OS setup, behaviour, and a number of other factors.

For example, let's assume you're a journalist trying to keep your identity quiet because you're studying a police corruption case. If your country's ISPs are protected by common carrier rules (i.e. the messages sent are legally protected in the same way that physical mail is) then transmitting content via the VPN is risky - the VPN provider isn't a common carrier and therefore doesn't have the same legal protection, but certainly does have information about you (billing information).

You've also got the problem that you're adding an additional point of failure. Your security relies upon both the VPN and Tor being safe - compromising one of the two means you're identifiable. Additionally, by connecting to a VPN you usually have routing rules which send LAN traffic through the VPN. This means that non-Tor data (e.g. NetBIOS, WINS discovery packets, DNS, OS / application update queries, etc.) might get sent through that same VPN channel, resulting in a log of your Tor and non-Tor behaviour occurring at the same time through the same endpoint.

The other problem is that commercial VPNs marketing themselves as privacy tools are obvious targets for threat actors. This means that by using the VPN, you might actually end up in a situation where someone has already compromised the server - it's not like you've got annual pentest reports from the VPN provider to take a look at and check they're running sensible and up to date systems. The benefit of Tor, in this regard, is that the communications are decentralised and distributed, which makes it much more difficult to focus attacks and traffic analysis from a logistics perspective.

I'd argue that the benefits of running Tor over a VPN are tenuous at best. The promise of additional privacy or security isn't backed by anything tangible or measurable, aside from the perception that complexity adds security.

Regarding your edit, if the person is using Tails and safely uses Tor, it makes no difference whether you just use Tor or use a VPN with Tor through it really. Which comes down to the crux of it: what does adding a VPN give you? I can't see any case where it provides any additional anonymity, particularly against a nation state, and then you've got the problem that if you're connected to some open WiFi somewhere (e.g. a cafe) you're then potentially tying your identity (from the VPN billing details) to your location, and the fact that you're using a VPN plus Tor. Not ideal if you're a journalist in an oppressive state, or a drugs trafficker trying to keep himself hidden.

Regarding your comment below as to why the VPN might be an addition point of failure, consider that some states would consider you in violation of a law if you simply used Tor. If you only use Tor, it becomes quite difficult to identify who you are if you're using public infrastructure like open WiFi or municiple networks. Once you add the VPN in, you add a direct purchase record back to your name and address. Not ideal.

At the end of the day, designers of secure systems should be resistant to adding additional components and features, due to the additional complexity and potential for unforeseen problems. This means that you should consider what benefit is added by including a VPN in your chain. I can't really see one, aside from a situation where use of Tor would be illegal but use of a VPN to another country would not be illegal (I'm unaware of such a case existing).

One additional potential issue, which I forgot to mention above, is the increase attack surface against the client-side. By adding in a VPN client on top of the Tor client, you've got another piece of software which may contain bugs (e.g. remote code execution).

As an aside, I'd also like to point out that VPNs are not and never were designed to be privacy or anonymity tools. They are marketed as such by people who sell VPN services, but any anonymity or privacy you gain from them is incidental rather than purposeful. They cover but a fraction of the threat landscape in this space; mostly they're only useful as a tool for avoiding ISPs' blocking of certain sites (e.g. torrents). Nobody who is serious about anonymity and privacy, particularly in a situation where their safety, freedom, or even life is on the line, should ever use a VPN as their privacy solution.

Additional edit: There is one very specific circumstance where adding a VPN does provide additional security, and that's when VPN traffic won't draw attention but Tor traffic would. This is the only case where a VPN offers a benefit, at the potential cost of increased identifiability should someone actually take a look at what was sent through the VPN.


Why can't bypass SOP using "src" attribut in script tag?

Because step 4 is impossible. Not just because of the same-origin policy, but because there's simply no way to retrieve the content of a script tag via JavaScript.

There's HTMLScriptElement.text, but that only retrieves the text between the script start and end tags. It can't retrieve content loaded via the src attribute.

That said, there actually is a way script tags can be used to bypass the same-origin policy under limited circumstances. If you load a script from another domain and execute it, then you might be able to derive some information from the side-effects of that execution. That's how JSONP works. This isn't usually a security issue though, as most JSONP endpoints are designed with cross-origin access in mind, and most other types of scripts are static assets that do not contain sensitive information.


Thanks to @user, who led me to the correct answer - You must simply use hex tab, and then find carriage return character you want to delete. Afterwards just click the Right button and press Delete Byte option.


nmap really isn't designed to do what you're looking for. You would have to know exactly what you are looking for and grep the output for those things, just like you did in your example. But that will only work if the printer responds to pings, and if printers return the results that you expect.

You might be able to eliminate some results by knowing what the OS is on the printers and eliminating results that do not report that OS.


Passive WiFi sniffing without associating to the AP

Basically, you are asking two different things here:

Can I log all wifi traffic which I can physically pick up in a specific location, i.e. where I am within the range of both sender and receiver?
If so: Depending on the amount of networks and traffic, this will yield a substantial amout of raw data (haystack) in which you need to look for whatever you are interested in (needle). Are there any tools which can help me with that?

I don't know of any specific tools, but you could start by writing some scripts which will create a folder for each station you are reading and put files in there. Other than that, look for big data tools. Elasticsearch might be a starting point to identify packets which are of interest to you.


Combining capability-based access control with SAML

I'm not familiar with XPOLA, but here are some resources on using capability-based authorization on the web that you should read:

Alan Karp at HP Labs is doing work in exactly this area: capability-based security for web services, including using SAML and similar standards.  Take a look at his work.  See, e.g., the following papers of his:

From ABAC to ZBAC: The Evolution of Access Control Models.
Solving the Transitive Access Problem for the Services Oriented Architecture (discusses using SAML certificates for capability-based security)
Authorization-Based Access Control for the Services Oriented Architecture (more discussion of use of SAML certificates)

Webkeys bring capability-based security to the web.  It is a detailed, worked-out proposal for how a URL can serve as a capability, and how to build web services on this substrate.
The Waterken server is a capability-based approach to web security, which allows deploying non-trivial computation and coordination between entities using object capabilities as the security model.  See, e.g., some of the talks from Tyler Close.
The cap-talk mailing list is the leading place where capability folks hang out and share information about the capability-based approach to security, including web security.
For more background on capability-based systems, read Wikipedia's entry on object capabilities, Jonathan Shapiro's essay on What is a capability, anyway?.  See also Kragen Sitaker's rant on capabilities and the web, or Doug Crockford's more recent talk on capability-based security and the web (it focuses more on fine-grained sharing, including on the web side, rather than web services design, which I think you are more focused on).


Password policies for randomly generating passwords

I can guarantee you that we could easily find two sites that have entirely incompatible password policies. It'd actually be easy: find one site that requires special characters, and another site that bans them. Done. So there's no one-size-fits-all solution.

I think your best bet is to generate random passwords in a form that'll mostly work for sites - upper, lower, numbers, and a reasonable length. I've used a UUID-type string or even a truncated MD5/SHA1/whatever hash of /dev/urandom in the past. Then give users the option to enable "special characters required [/forbidden]", max length, etc options. A more complex option is to build-in the policies for the weird sites as they come up, but that'd be nightmareish probably.

FWIW, I'm a strong believe that unique passwords (ie, using a password manager) is vastly more important than using strong passwords in most cases (the main exception is when the attacker can perform an offline attack, like a full-disk encryption password). So I would worry more about making the integration easy (and making the password manager itself secure!) than having the strongest possible passwords. I can talk about that all day, happy to expand on it!


Is there a way to allow users to submit their username and password from an insecure site without compromising security?

No. As you realized yourself in your question the site could be compromised and everything replaced. And this could be done in a way that the user is not aware of this.

Training the users to trust such an insecure site is a bad idea because not only the login credentials could be grabbed but the trust in this site could also be used in social attacks. For instance the site could claimed that a plugin or browser update is needed to continue and thus make the user install malware.


I'm going to knock some of the bad notions here:

1) Linux is more secure because of less marketshare.

Not in the server market, where public machines get slammed by bots, viruses, hackers, etc. all day:

http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Servers

2) Windows is more secure in recent versions.

At least at the kernel level, you're seeing more CVE reports of remote execution exploits and privilege escalation in Windows, more local DoS attacks to a multi-user environment in Linux, also you'll find more critical CVEs on Windows (I had a bunch of statistical breakdowns from a CVE database but I can't find that post I made months ago, so frustrating! Google isn't helping me find it...).

As you can see Server 2008 has a much higher weighted average of CVE severity:

http://www.cvedetails.com/top-50-product-cvssscore-distribution.php (plus, all Linux vulnerabilities from the 1.2 days vs the past 5 years of 2008 development!)

Of course you run with something like Ubuntu that comes with a bunch of software and pre-configuration on top of it, they're at the whim of the software running on it.

My opinion on the subject: Linux is built around a lot of Unix concepts, 40 years of software development and people beating these boxes to death, it is secure mainly by Unix's trial by fire, and this has helped immensely, lots of lessons were learned and directly applied to Linux.

  Has this got anything to do with the Open-source nature of Linux?

A lot of it has to do with that, at least with the speed at which the higher volume of CVEs are addressed. This also allows a lot of smaller issues to be found and fixed (mainly due to it's popularity, because open-source with no popularity means few eyes on the code and little interest to fix).

  Its underlying architecture (and the difference from Windows)?

Being built up around a multi-user environment helps a ton, these systems were built to have tons of people on them at once, and no one user should be able to interrupt another.


The ZIP format supports several variants of password-protection of a file.

The early password protection system in ZIP is known to be seriously flawed. However, later versions of the format provide far better protection, including support for stock encryption algorithms like AES to which no known attacks exist.

The author of the video appears to be using WinRAR. RARLabs, developers of WinRAR, try to promote their proprietary RAR format, and claim that ZIP does not support AES encryption. That's simply misinformation, considering that competing products like 7-zip do support it. I would suspect that they intentionally use a weak implementation of ZIP to make their own format look better in comparison.

But Nullsoft Installation System (NSIS) does not actually seem to contain a cracker for weak ZIP archives. Why should it? It's a sofware for building installers, not a cracking tool.

Notice that the presentator does not try to actually open any of the unpacked files. The directory structure of a ZIP archive isn't encrypted, so it can be read without the password. Working with encrypted archives is quite out of scope for an installer builder, so the developers likely didn't even bother to detect encrypted files. A telltale sign that the unpacked files are in fact just garbage is this screenshot from the unpacked directory at 11:00.

Notice something? Hint:

   The only visible file here shows a filesize of 0 bytes. The other unpacked files likely don't look much better.


Single-use password as the default authentication method?

Are there any sites which use this approach?

This sounds very similar to Yahoo's on-demand passwords.

  Yahoo announced that in lieu of a standard username-password combination, Yahoo users in the US could log into their accounts with one-time passwords sent to their mobile phones via SMS message.

  Are there security issues with this approach?

Yes, like the email approach is vulnerable to an attack on an email account, this is vulnerable to an attack on a device. The device could be stolen, or if it is a smartphone malware could be engineered to access SMS messages and send them to an attacker. Also, consider what happens if the phone is lost or the SIM expired (say it was an old phone and you only just realised you needed it to access your account).

  The crazy password requirements lead me to a situation where there is
  no way for me to memorize the passwords to the several sites that make
  those requirements.

  The result is that every visit to those sites is a password recovery
  exercise (click on the password recovery link, answer a personal
  question, receive a text message with a code or an e-mail with a link,
  enter the code/visit the link, invent a password that I will never use
  again, finally access the site).

This is already a solved problem. Get yourself a password manager, protect all your accounts with a strong, memorable master password and then you can retrieve everything without remembering individual username and password combinations.


Separate certificates on a local machine for each service

Yes, it is.
A certificate is simply a file, and so is the corresponding private key. You can place multiple certificates with their private keys on a machine and point each software to a different certificate.


If Postgres trusts localhost connections, is it dangerous to visit random websites?

You basically rely on the strictness of the PostgreSQL protocol parser. In the past there were several attacks where too much tolerance against malformed input made attacks from the browser possible, even though the browser did not correctly speak the application protocol. See for example HTML Form Protocol Attack or more recently NAT SLIPStreaming. This made the browser block several ports for outgoing connections, but notably the default PostgreSQL port 5432 does not seem to be one of these.
While it might work in this specific case it is a bad idea on general to rely on the unknown robustness of a implementation. This is especially true if there are other options: PostgreSQL can use UNIX domain sockets. With UNIX domain sockets these are not only safe against access from the browser but also the access from other users on the system can be much easier restricted, since UNIX domain sockets will use file system permissions (i.e. user, group, ...) for access control.


Encrypting file in Javascript before sending them to Google Storage

Firstly I'd like to propose an edit to your question.

  "The client WILL not have access to the file once it is done uploading
  it."

to

"The client SHOULD not have access to the file once it is done uploading it."

You should always consider that a malicious actor could retrieve your data from storage and consider if your assets are appropriately protected if that happens.

Considerations here are that you should never expose an encryption key to anyone that you do not want to have access to the data.

You should consider how secure and how random your random key generator is, that anyone with access to the javascript can see how it works and could potentially predict keys and also that you are then sending this key over to the server which could be visible to certain MITM attacks.

You are much better off in this case using asymmetric encryption, encrypting on the client side with the public key and allowing decryption only with your scret private key


Is it possible for Firefox to detect MITM attacks by the enterprise?

As long as the browser itself is unmodified, you can detect MITM by checking the certificate chain by clicking on the padlock icon next to the URL bar. When the connection isn't being MITMed, the root of the certificate chain should be a public CA. All public CA publishes their public key hash or you can cross check the root's hash against the root store you download directly from Mozilla. If you are really paranoid, you want to download the root store from a connection that you know for sure is secure. You can also audit the browser's root store (using the built in certificate manager) against the securely downloaded root store, to check that the browser's root store doesn't contain any additional roots that shouldn't have been there.

In practice, most Enterprise interception policy aren't meant to be hidden from their users/employees, so the CN field of the root certificate usually would clearly indicates that the root certificate belongs to the enterprise rather than one of the Public CA. Therefore, a much simpler way to detect MITM in this case is to simply check the name in the "Verified by:" field in the padlock icon popup. This is slightly less robust though, because it depends on the enterprise not deliberately going out of their way to try to hide that they're intercepting.

If the browser is modified, then all bets are off as the browser can lie to you. Note that installing a classic (non-Webextension) add-on counts as modifying the browser.


If I host a web form which submits CC details to a provider, are there PCI implications form host?

How are you handling the cc details? I'm afraid that PCI compliance is a lot more than https,

We used to host a form directly and pass on the information to the processing company within a script, not even storing them as session variables. That was reason enough for our bank to bump up our PCI requirements as we handled the cc details directly. If you imagine somebody put some dodgy code on our server, it could do anything it liked with the credit card details.

We now use an embedded iframe from our card processing company within the webpage. It doesn't look quite as good, but we never see the cc details, so our PCI compliance burden is greatly reduced. It wouldn't matter what code is on our server now, the credit card details can't be accessed.

A good starting point would be https://www.pcisecuritystandards.org/index.php, pick your self see where you put yourself and then go from there.


How could Craig Wright obtain Satoshi Nakamoto's private key?

Wright did not obtain Nakamoto's private key.

What he did provide as evidence was a signature from one of the early bitcoin transactions. However, that signature is from the blockchain and can be looked up by anyone.

Wright was able to fool some people from the mainstream media who don't really understand the technical details, but the security community debunked it quite quickly. Security Researcher Dan Kaminsky tweeted on May 2nd:

  Satoshi signed a transaction in 2009. Wright copied that specific signature and tried to pass it off as new.

Also, the official Twitter account of the Bitcoin Core Project tweeted on May 2nd:

  There is currently no publicly available cryptographic proof that anyone in particular is Bitcoin's creator.

By the way, The Economist, the original news outlet who started spreading the claim, has now published a correction.

A proper proof of Nakamoto's identity would, for example, be a message reading "My real name is Craig Wright" signed with the Satoshi Nakamoto PGP key or a new bitcoin transaction from a wallet confirmed to be owned by Satoshi Nakamoto. But so far this hasn't happened.

Gavin Adresen, chief scientist at the Bitcoin Foundation, claimed to have seen such proof by Wright, but has not posted that proof publicly. Why he would make such a claim without providing any evidence whatsoever for it and expects the world to just trust his word is a mystery. Convincing people of a miracle solely by claiming very sincerely that you saw it with your own eyes might work in certain religious circles, but certainly not in the more scientifically inclined crypto community.

By the way: I am the real Satoshi Nakamoto. Prove me wrong.