Secure communication between two applications on the same system

These are the golden rule of computer security: "It is impossible to hide anything from a competent user with system administrator privilege" and "any competent user with physical access to the device can always elevate himself to system administrator".

You cannot hide any information from someone with physical control of the machine. If the secret you are trying to hide is really important, then you should never transfer the data to the machine and do your processing elsewhere in a place that you control.

Your program is running on a user's machine. You cannot protect your data from the user. With that in mind, does this mean we're doomed? Not necessarily. The operating system provides a wealth of mechanism for programs to communicate privately with another program that will not allow another unprivileged application to intercept it. So, while you cannot protect any data from the user themselves, you can protect your data from another unprivileged program. Providing security boundary between unprivileged programs is one of the main job of the operating systems.

The simplest of this is an anonymous pipe. A pipe allow a unidirectional stream of data to be transported between program. Anonymous pipe is available in Windows, Linux, OSX, and all Unix-like systems. Anonymous pipe most commonly recognized as a pair of pipe called stdin and stdout that allows a parent process to send and receive a stream of data to and from its children. Anonymous pipe can only be used between processes that have parent and child relationship. There is also a named pipe, but they behave differently in Windows and in Linux/Unix-like systems, we will get back to this later.

Another IPC that are commonly available is sockets. Sockets is like a bidirectional pipe. There are many different sockets but they work similarly. The most commonly known is TCP socket. TCP socket is primarily intended for networking between machines but you can also create a loopback TCP socket which can only be used within the same machine. A loopback socket provides privacy (only the program the program that connects and the program that listens can read the data passing through the socket), however it does not really provide mechanism to restrict who can be the other side of the socket.

Another type of socket available in Unix for communication between processes in the same machine is Unix Domain Socket. A Unix domain socket is exposed to programs as a "special file" in the filesystem, and unix filesystem permission is used to control access to the socket. A domain socket cannot be connected to by programs that does not have the right access permission to access the socket file. In Unix-like systems, this means that your service and GUI should run as the same user and/or group that are reserved only for your program and you set the socket file permission appropriately.

Let's get back to named pipe. In Linux/Unix-like systems, a named pipe is pretty much like stdin/stdout in that they are unidirectional. In Windows, however, a named pipe is actually bidirectional and is pretty much the equivalent of Unix domain socket in Windows. Like a lot of things in Windows, named pipe is secured with ACL.

With iOS things becomes a bit hairy. A non-jailbroken iOS only allows a very limited set of inter-process communication, and neither will give you a socket. But if we play loose with definition, in the iOS application, the service program and the GUI program is probably going to actually be the same application, and thus you can simply create a stream directly between different components of the application. This is also secure as the stream is accessible only within the application.

Android provides more options for IPC, including the ability to create domain socket. The API is different but they are conceptually similar with regular Linux. Alternatively, you may go the same approach like in iOS and package your service and GUI in the same application and just use in-process streams.


How to dump the memory of a given process with Volatility 3?

To dump the whole memory (not only binary itself) of the given process in Volatility 3 you need to use windows.memmap.Memmap plugin with --pid and --dump options as explained here.
For example:
vol.py -f mydump.vmem -o /path/to/output/dir windows.memmap.Memmap --pid 1233 --dump


Decrypting TLS in Wireshark when using DHE_RSA ciphersuites

Some background: Wireshark supports decryption of SSL sessions when the master secret can be calculated (which can be derived from a pre-master secret). For cipher suites using the RSA key exchange, the private RSA key can be used to decrypt the encrypted pre-master secret.

For ephemeral Diffie-Hellman (DHE) cipher suites, the RSA private key is only used for signing the DH parameters (and not for encryption). These parameters are used in a DH key exchange, resulting in a shared secret (effectively the pre-master secret which is of course not visible on the wire).

Wireshark supports various methods to decrypt SSL:

By decrypting the pre-master secret using a private RSA key. Works for RSA key exchanges and subject to the above limitation.
Using a SSL keylog file which maps identifiers to master secrets. The available identifiers are:

The first 8 bytes (16 hex-encoded chars) of an encrypted pre-master secret (as transmitted over the wire in the ClientKeyExchange handshake message). (RSA XXX YYY, since Wireshark 1.6.0)
The 32 bytes (64 bytes hex-encoded chars) within the Random field of a Client Hello handshake message. (CLIENT_RANDOM XXX YYY, since Wireshark 1.8.0)

A variant that maps the Client Random to a pre-master secret (rather than master-secret) also exists. (PMS_CLIENT_RANDOM XXX ZZZ, since Wireshark 2.0)
Another variant exists to support TLS 1.3 and maps the Client Random to respective secrets. Instead of CLIENT_RANDOM, the key is one of CLIENT_EARLY_TRAFFIC_SECRET, CLIENT_HANDSHAKE_TRAFFIC_SECRET, SERVER_HANDSHAKE_TRAFFIC_SECRET, CLIENT_TRAFFIC_SECRET_0 or SERVER_TRAFFIC_SECRET_0. Since Wireshark 2.4.

The Session ID field of a Server Hello handshake message. (RSA Session-ID:XXX Master-Key:YYY, since Wireshark 1.6.0)
The Session Ticket in a Client Hello TLS extension or Session Ticket handshake message. (RSA Session-ID:XXX Master-Key:YYY, since Wireshark 1.11.3)

To generate such a SSL key log file for a session, set the SSLKEYLOGFILE environment variable to a file before starting the NSS application. Example shell commands for Linux:

export SSLKEYLOGFILE=$PWD/premaster.txt
firefox

On Windows you need to set a global environment variable, either via cmd (invoke setx SSLKEYlOGFILE "%HOMEPATH%\Desktop\premaster.txt" for example) or via the System configuration panel. After doing so, you can launch Firefox via the icon. Note: (Linux) users of Firefox with NSS 3.24+ are possibly unable to use this method because Firefox developers disabled this by default.

The SSL key log file can be configured for Wireshark at Edit -> Preferences, Protocols -> SSL, field (Pre)-Master-Secret log filename (or pass the -o ssl.keylog_file:path/to/keys.log to wireshark or tshark).

After doing this, you can decrypt SSL sessions for previous and live captures. Should you encounter a situation where you still cannot decrypt traffic, check:

whether the key log file path is correct (use absolute paths in case the program changes the working directory).
whether the key log file actually contains key material for your program.
whether Wireshark was compiled with GnuTLS (I have tested Wireshark 1.10.1 with GnuTLS 3.2.4 and libgcrypt 1.5.3)
whether other sessions can be decrypted. For instance, I tried https://lekensteyn.nl/ which works, but a site using a Camellia cipher suite failed.

If you still cannot decrypt all traffic, it is possible that Wireshark contains a bug (in my case it was missing support for Camellia). To start debugging, save your capture and start wireshark with SSL logging enabled:

wireshark -o ssl.debug_file:debug.txt savedcapture.pcapng

After the capture has been loaded, you can close the program again. (You do not actually need to save the capture, but it makes it easier to reproduce the issue and avoid further noise in the log dump.) You might see something similar to the line below:

ssl_generate_keyring_material not enough data to generate key (0x33 required 0x37 or 0x57)

These numbers are a combination of the constants defined in epan/dissectors/packet-ssl-utils.h:

215-#define SSL_CLIENT_RANDOM       (1<<0)
216-#define SSL_SERVER_RANDOM       (1<<1)
217:#define SSL_CIPHER              (1<<2)
218-#define SSL_HAVE_SESSION_KEY    (1<<3)
219-#define SSL_VERSION             (1<<4)
220-#define SSL_MASTER_SECRET       (1<<5)
221-#define SSL_PRE_MASTER_SECRET   (1<<6)

As you can see, I am missing the SSL_MASTER_SECRET (0x20) here. Looking further in the log file, I can also find:

dissect_ssl3_hnd_srv_hello can't find cipher suite 0x88

This cipher suite is indeed missing from the cipher_suites structure defined in epan/dissectors/packet-ssl-utils.c. After studying RFC 5932 - Camellia Cipher Suites for TLS, I found the required parameters for a CipherSuite.
The resulting patch should then be submitted to Wireshark as I did here: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9144. The stable 1.12 series have vastly improved cipher suite and TLS support, so you should not have to manually patch it now.


Do external harddrives keep track of the computers they're plugged in to?

In my experience I have never seen any storage devices that does this by themself.
As others in the comments has mentioned: Some information like hours powered on, the number of timed powered on and some other information are stored in the hard drive and are accessible using SMART.
However, many operating systems including Windows, macOS and Android will create files on connected storage devices.
Windows will create a hidden system folder named System Volume Information.
MacOS will create a hidden folder named __MACOSX and perhaps .DS_Store.
Android will create a folder named Android.
Other OSes might create other folders.
Depending on your needs, wiping a hard drive (with physically spinning disks) should be secure enough if totally wiped at once or more, or even destroying it physically should be of help, but even a severely damaged hard drive might still make it possible to retrieve some information from it, so drilling holes, sanding the plate and apply a strong magnetic field to them and dispose of the pieces might be the best thing to do.


How to protect source code that resides on virtualbox web server which starts at boot?

Virtual machine, but real CPU. Regardless of how you elect to see it, the code for your server still runs on the machine of the supposed attacker. Similarly, disk encryption of any kind would not help either, even if you personally typed the password yourself upon boot: at some point, the data is still decrypted, on the attacker's machine.

Virtual machines don't offer any protection against that kind of inspection. VM protect the host operating system from the guest, not the other way round.

This is one of these situations where "go Cloud" is a good advice. Don't give a USB Flash drive; instead, host the code on a server somewhere. That way, you keep control of the whereabouts of the data and who reads it.


Are externally referenced libraries (CDN's) a security issue?

The answer to this question has two sides...

First:

If you host the libraries yourself then you have to check the security notices on the library regularily and update the library accordingly. This can be a very time consuming task if you include several libraries which must be updated independently.

On the other side you can audit each library you use.

Additionally you have to prevent any attack to this libraries yourself. If you detect an attack you can handle this very fast.

Second:

If you use a CDN then the ownder of the CDN updates all libraries for you. You have no work with updating the libraries yourself.

The audit for the libraries are (hopefully) done by the company of the CDN. You cannot influence this audit.

A CDN should prevent any attack to the hosted libraries. If an attack is detected then the CDN will handle this attack. Perhaps the libraries are compromised and the CDN is delvivering modified libraries which can infect your customers...

Finally

The CDN lowers your work with the libraries as they do much work that has to be done by you otherwise.

On the other side you have to trust the company of the CDN to handle all security issues fast enough to not harm your customers.


Steffen Ullrich has the correct answer. Snort is a program on your computer. The program looks at traffic on a network interface. The traffic is 'exiting' at your machine, from the VPN. The Snort program can see this traffic as it exits, as it has been decrypted. The command that Steffen posted is telling snort to look at traffic on an interface called 'tun0'. The interface may otherwise be named 'tap0' or similar, depending on VPN used.


Yes, MDK3 sniffs traffic to find targets.  This allows it to find the proper source address(es) for the Deauth packets to be sent.  MDK3 also appears to send deauth packets in both directions to ensure the AP drops traffic from the client as well as the client disconnecting from the AP.


Implementing brute force attacks on hash values in Javascript

First define the space of potential passwords. Then number them sequentially.

For instance, suppose that you define the possible passwords as "sequences of eight letters and digits". This is an alphabet of 62 signs (26 lowercase letters, 26 uppercase letters, 10 digits). So there are 628 = 218340105584896 passwords to try. Passwords are easily mapped to integers in the 0..218340105584895 range by considering the passwords to be a base-62 representation (i.e. 'a' is 0, 'b' is 1,... 'z' is 25, 'A' is 26,... 'Z' is 51, '0' is 52... and '9' is 61). Now that the potential passwords are just integers in a consecutive sequence, it is easy to distribute ranges.

Of course, performance of hash function implemented in Javascript will be very disappointing. A single PC with a good GPU can try more MD5 passwords than 1000 clients who use Javascript. You might want to make versions which use Java and/or .NET (Silverlight): these programming languages have much more muscle (not quite as good as C, but at least in the same magnitude order).

Edit: from your comment, I understand that you also wish to keep the target hash somewhat private, and not send it to the cracking machines. This forces the cracking machines to send back all their hashes (or part thereof) to the server, and you will have a bandwidth problem. Each cracking machine could send back, say, only the first two bytes of each computed hash; the server then knows which password candidates match the target hash on the first two bytes. This would reduce the problem by a factor 65536, and then the server can finish the work itself (retesting the matching candidates on its own CPU). However, with a 10 MBytes/s incoming bandwidth, you would be able to receive only about 5 millions hashes per second, and if you target a "simple" hash (like a single iteration of MD5), then this is very poor performance (the server alone, on its own CPU, can test many more passwords per second). This would be a valid scheme for a slow hash (like bcrypt) where each cracking machine will be able to compute a hundred hashes per second at most (but then, you really do not want to use Javascript...).


@tim is right. The exploit uses the sequence %0D%0A%20 which is URL-decoded to CR + LF + SPACE and thanks to the extra space could bypass the response splitting protection in some browsers.

There was once a feature called line folding that allowed HTTP headers to span over multiple lines by prepending every additional line with a space or tab. It was later dropped in RFC 7230, though. So it happened that Internet Explorer treated header continuations with leading spaces as if they were multiple individual headers while PHP did not yet implement the RFC, leaving IE vulnerable to the space trick. This issue was addressed in February 2015 (bug #68978) and finally implemented in PHP 5.4.38, so version 5.4.7 was still affected back then.

From the changelog for 5.4.38:

  Removed support for multi-line headers, as they are deprecated by RFC 7230.

You can see in the corresponding commit that header() now completely rejects any carriage returns and line feeds, regardless of their position. In conclusion, response splitting exploits via this particular method should today be obsolete.


What local ethernet-accessible resources can be accessed on a PC through a USB cable?

As far as I know there is no direct USB connectivity possible between two normal computers that is also usable at the same time as a network (which is what you need to scan). I don't even think that you can simply connect two PCs using a simple USB cable, since PC usually only support the USB host mode and with USB one device needs to be in host mode and the other in device mode. And to support USB device mode on a PC you not only need special software but also the hardware explicitly must support it.


Is he using your credit? If so contact Apple.

If he's not, then he just might have the same name as you and he's not really doing anything wrong. What you can do is send an email to apple making them aware of the problem so they can force the user to choose a new email address. Since you do not own the apple account, it's not really your right to change the password.


I have one Friend that said he is getting texts from me but its not me

It is possible to send a text message to a phone via almost any Email service.
There are email to SMS gateways for each provider, and there is a specific email suffix for each provider. For example, to text a number 1234567890 that happened to be an ATT number, you would send an email to 1234567890@txt.att.net.
People can change their name in email services to whatever they wish, so it appears they are simply sending an email with your name entered in the email service configuration. The phone takes that name information and displays it along with the text message. It appears that this is simply an email to SMS message, and not an SMS spoof which would display an actual phone number and not an email address.


Yes, this approach will certainly help protect your host OS. As a matter of fact, it's an approach I take for most untrusted applications I use, including browsing untrusted web content.

This however is not an absolute way of protecting your host system, it simply increases the attacker's workload substantially. And as a matter of fact there have been exploits that enable applications to escape the virtual "sandbox."

For added security, you should save your guest OS in a known clean state and revert to it after each use.


P12 - Extract public part (certificate) without knowing the p12 password

It can be done with openssl. In a terminal type:

openssl pkcs12 -in myfile.p12 -nokeys -nomacver

And just press ENTER when the import key is requested. The certificates contained in the PKCS12 file should be printed (en PEM format) on the standard output.

NOTE: even if the certificates are present in plain text in the PCKS12 file, the file full content integrity is protected by a Message Authentication Code (MAC). Without the password you are not able to verify that the file has not been modified and it means that anyone who could access the file would be able the add, remove or modify the certificates. It may be a security concern, not necessary in your case, but you should keep that in mind if you want to reuse that tip in other circumstances.


is browser the only app that can set supercookies?

I'm not sure how well defined app is in this case. Depending on which browser you are using, it is a collection of one or more processes. Browser plugins and extensions may or may not be running in their own processes.

If you assume that a supercookie isn't utilizing an unpublished browser vulnerability, then only the browser process, and processes that it communicates with, can store supercookies locally.

Regarding plugins and extensions, many of them make network calls so it is theoretically possible that they are tracking your information remotely. In that scenario, they would use some unique ID for your computer (maybe your MAC address) as the key into the remote database.

Generally, the best way to avoid tracking is to run in the browser's incognito or private mode. These modes are designed to prevent tracking of all types.


What is the use of private key of a SSL certificate?

Asymmetric private keys have two basic operations: they can Sign a message such that anybody with the corresponding public key can verify that the private-key-holder signed it and it hasn't been tampered with, and they can Decrypt a message that was encrypted using the public key. In addition to the direct usefulness of these operations, the private key can be used to prove ownership of a certificate; the certificate contains a public key, and the private key can (by using either signing or decrypting) prove to a third party that it is your certificate (assuming, of course, that the private key has not been leaked or cracked).

  Is this private key used to confirm that the certificate you send over the internet really belongs to you?

That's definitely one of the things it's used for, yes. That step is important for Authenticating the server in a TLS connection - proving that it's actually the server you mean to talk to - and can also be used to prove a TLS client's identity when client certificates are used (sometimes called mutual TLS).

The private key is also a critical part of the Key Exchange part of a TLS handshake, when the client and server agree on a symmetric public key that they both know, but that an adversary snooping on the connection or even actively tampering with it (as a man-in-the-middle) will not know. For RSA key exchange (common for a long time but somewhat rarer now), the basic procedure is simple; the client generates a random secret, encrypts it with the public key (from the cert), and transmits it. Only the holder of the private key can decrypt it. A more complicated (but more secure) key exchange uses some form of ephemeral Diffie-Hellman key exchange; in this case, the server signs the DH parameters (using its private key), and the client only accepts those parameters if they can be verified using the public key from the certificate. In either case, if the attacker attempts to tamper with the key exchange, the exchange will fail (in one case, neither the attacker nor the server would have the symmetric key that the client is using; in the other case, the client would reject the server's parameters and refuse to derive the symmetric key at all).


Does CryptoWall needs a internet connection to encrypt my files?

Short answer:

It will need internet connectivity briefly, then it will encrypt everything even if you disconnect.

Long answer

As soon as CryptoWall runs, it will generate a random RSA public and private keys, connect to one or more control servers, and upload the private key along with some information on the system it is, like OS version, public IP and location. Then it can run disconnected.

After generating the keys, the malware will proceed to encrypt every single file it supports. Some variants will keep the original intact during the encryption phase, and delete all original files after encrypting all of them. Some variants will encrypt and delete the original in one pass.

The server will keep the private key for some time, and you have to upload a sample of an encrypted file to them. They will send back the private key you will need to decrypt the files.

You probably have no chance of stopping the encryption process once it started. CryptoWall employs a number of defenses, and if you get caught by it, it's over. The encryption is well made too, so the chances of bruteforcing it is almost zero. Backups will not save you if your backup drive is connected to the PC all the time, as CryptoWall will encrypt your backups too.


By overwriting eip do you mean to directly overwrite ret address or fill the stack with some buffer

Because usually when there is a stack without canary and a bof present you can basically fill the buffer with nop+shellcode+addrof buff (generally on stack or some writable memory)

So the eip points to the address of the buffer on stack and hence the shellcode in buffer would be executed


Rainbow tables/hash tables versus WPA/WPA2

WPA/WAP2 does not use a dedicated random salt.  Instead, it was designed to use the SSID as a salt value.  This is better than no salt but it does mean some access points are vulnerable.  For quite a while most routers would ship with a static SSID ('linksys' or 'default').  So while hackers can't just precompute a single set of passphrases they could precompute common passwords against common SSIDs. Church of Wifi has some rainbow tables (1 million common passphrases for 1,000 common SSID = 33GB) as well as general information on wifi cracking.
http://www.renderlab.net/projects/WPA-tables/
So WPA/WPA2 isn't as bad as WEP but relying on a low entropy value like SSID made it more vulnerable than it needed to be.  That vulnerability was made worse by companies shipping hundreds of millions of routers for years with static SSIDs.  Many people never changed them, and some who did picked other equally bad/common SSIDs.
The most common SSIDs
linksys
<no ssid>
default
NETGEAR
Wireless
WLAN
Belkin54g
MSHOME
home
hpsetup
smc
tsunami
ACTIONTEC
orange
USR8054
101
tmobile
<hidden ssid>
SpeedStream
linksys-g
3Com
WaveLAN Network
Wayport_Access
hhonors
pi07490509x
pi07490509x09
Motorola
SST-PR-1
ANY
eurospot
188ALT
Gateway
HomeNet
GoldenTree
SITECOM
ConnectionPoint
<No current ssid>
Philips WiFi
Customer ID
PCX5000
arescom
Wireless Network

Today most routers use a pseudo-random SSID like linksys_AUENFJS22 instead of just linksys but there are a lot of vulnerable hotspots out there.
The hashing function is PBKDF2 which uses multiple rounds to slow down attacks.  The entire authentication process is far too complex to be a good fit for SO.
To protect yourself from precomputation you should ensure you use a unique SSID.  One thing I have seen more than once is someone thinking they are secure by disabling the SSID except that is common enough that it became an entry in most rainbow tables.


Does multiple numbers per button have an effect on security?

Think about the technical implementation, not about the user or what's painted on the buttons: it's a keypad with 5 buttons. In order to unlock the device, it needs a sequence of those 5 buttons (however many presses of those 5 button it allows).

More buttons would make it harder to brute-force the combination. Imagine having only 2 buttons, or imagine having 20. More buttons would mean more possible combinations, more combinations means harder to bruteforce.

I can imagine one way where having fewer buttons might increase security: smudges. If you had 20 buttons, over time, the few buttons you used would appear to be used, thereby reducing the number of possible buttons to try, including being able to deuce the number string ("123456") that the user needed to remember. Fewer buttons (with multiple numbers per button) means that smudges are less meaningful (they are all smudged), and a reduced possibility of deducing what the memorized number sequence was. But, this is only one aspect of security, and one I might not value too highly on a residential house lock.


Using Lynx on potentially malicious websites

You are greatly reducing your surface of attack by using lynx or similar, for example they don't run Javascript nor try to decode and display images so any vulnerabilities in these components don't affect it.

But in theory, you are still vulnerable. Even in Lynx there are still components that parse HTML, interact with the network, keep track of cookies, etc (tip: use curl or wget to just download the page without even parsing it to be even more careful). That is still quite a big attack surface, though I would consider it safe enough at this point. Maybe not safe enough against a targeted attack from a powerful attacker, but definitely safe enough for random Android websites.

Note that while the site itself didn't compromise you, any tools you would download and execute from there could be malicious, including the Android ROM or whatever you wanted to download - I suggest you carefully check out why was the site blocked and make your own assumptions about whether it's safe (I would say it's not safe unless it comes from the phone's manufacturer, Google or a known open-source project and I can verify the file is authentic by checking hashes published over HTTPS or a GPG signature).


Why does this XSS vector work in svg but not in HTML?

HTML <script> has special powers other elements don't: it is a "CDATA element". That means that any < or & characters up to the end of the element are taken as literally meaning those characters. So what is passed to the JS interpreter is:

alert&#40/1/.source&#41

which is obviously not valid JS syntax.

The concept of a "CDATA element" comes from the SGML world from which HTML developed. But SVG comes from the XML world where things are simplified and there are no CDATA elements. Consequently the SVG <script> element has no special powers: inside an SVG script, < introduces a tag and & introduces an entity or character reference.

Consequently the &#40 gets parsed to ( and the resulting string passed to the JS interpreter is:

alert(/1/.source)

In XML terms the <script> element is in the HTML namespace and the <svg><script> element is in the SVG namespace, so they are different elements. HTML5 makes this all less clear by hiding the namespace prefixes and applying a non-XML parser to the SVG (which is why &#40 works despite it being non-well-formed; should be &#40;).


Securing REST API without sending or storing clear credentials

As pointed out in the comments, ssl/tls will protect your credentials in transit.  Encrypting traffic is part of the purpose of the protocol.  The other major purpose of the protocol:  verifying that you are communicating directly with the party you think you are communicating with.

The OP said that ssl proxies are possible and has seen it in action for mobile applications.
It is true that ssl man-in-the-middle proxies exist, but the client will warn that the server it is talking to has failed to present a valid certificate (and if the client is a browser, not proceed).

If your Rest API is configured to ignore bad SSL certificates (and some are - i know, I've written one), then, yes, a ssl MITM proxy would indeed be able to sniff your credentials.  This is purposely subverting the SSL/TLS protocol (you can't say you are using SSL/TLS in this case).
This is why "self-signed" certificates are only for development and testing purposes.


I‘m especially concerned if someone was able to get access to backend code and therefore acquire the SQL credentials.

The database system should be accessible from a limited number of systems. Specifically, it should not be accessible from the internet. If someone has the SQL credentials, they still won't have access to the server.
Common sources of leaks are:

SQL injection
Unauthenticated server exposed, such as MongoDB, ElasticSearch
Export CSV or document exposed, e.g. through Google Drive
Open Amazon S3 bucket
Data exfiltration after hack

My idea is to encrypt table data symmetrically with username and password of the user.

Most web applications have their data plaintext in the database, and simply check with business logic in the application whether a user may access a certain object. What you propose would give better security, but would also introduce more complexity. Think about whether it's worth it.

This makes it very difficult though when handling password resets...

When encrypting data with the user's password, that data is gone when the user forgets his password. In some cases, this is acceptable and the user should just create a new account. Otherwise, this is sometimes solved by giving the user a decryption key when setting up their account, which they are meant to print out and save. This is a "backdoor" key which can decrypt the account when the password is forgotten.


Are there risks in not having a edge firewall?

The concept is easy...think about when you travel into another country...the government inspects you (essentially) to see who you say you are and what you are planning on doing in their country. Now image if there were no customs/boarder patrol - anyone could go anywhere and could travel along pre-designed roadways & intersections (routers & switches) and you could cross boundaries like bridges (NAT) but there would be no security authority to govern what you did, where you went, and what your intents were. Basically, if you cannot inspect traffic then what good is your security?

Firewalls/UTMs (Unified Threat Management) devices are not synonymous with NAT or Routers. Yes, firewalls are security appliances & are always needed/essential at the Gateway! Their sole duty is to inspection ingress/egress traffic looking for threats and/or violations of policy. Without a firewall how would one protect against the following:

Encrypted payloads such as Ransomware, Zero-Day attacks
Rogue Services within the network such as blocking outbound DNS except for Authorized servers
Flood attacks
PoD (Ping of Death) attacks,  provided you require ping for the WAN - for monitoring, etc.
TCP State Manipulation DoS
DoS (Denial of Service)
DNS Rebinding attacks
IP Spoofing attacks
Intrusions
Malware & Spyware
Botnets attacks
Geo-IP attacks
Content-related attacks from the LAN (HTTP Proxy, Avoidance Systems)
Application behavior & control in all Zones - being able to thwart SSLv2, SSLv3, SSLv3.1/TLS1.0 traffic, stopping specific applications outside of your Authorized App Library

You need a firewall to provide inspection as a security baseline, which should include at the very, very minimum DPI (Deep Packet Inspection) & SSL-DPI (encrypted packets). Routers & switches were never designed to be security appliances with the capabilities to perform in this manner and neither was NAT.


Is publishing your public IP address a security threat?

Your public facing IP address is for most intents and purposes public information.  No security should be dependent on it being private, however it's not something you want to wave around willy nilly necessarily (just like you wouldn't wave your home address around) but it also isn't something that is hard for someone to find with generally minimal effort if they know what they are doing.

If someone has a legit need for your IP address though, there is no reason that it should be a security red-flag.  Your public IP address is disclosed to every system you talk to on the Internet by necessity.


Basic security checklist for using an open-source library

There is a difference between serverside and client side here. Since your talking about scrollbars and markdown editors I assume this is client side. I would be less concerned with client side problems, since most modern browsers pick up on security issues fast. In addition to that, browsers try to limit security risks, and sometimes act on the behalf of the user (malware detected, invalid xhr requests).

Client Side

Backdoors are rather uncommon for these libraries or any piece of client side software. Thought they do exist, HTML5 and the modern web have driven browsers to implemented some tricks to prevent malicious activities, for example; same origin, mixed content, popup blocks and iframe warnings, the remove of flash, activex and applets, and so on...

Server Side

Serverside is an other story. If you use third party libraries (whether they are opensource or not) you expose the environment in which the application runs. Often employed techniques such as jailing, autdits, permissions per application directory and per database (operation) minimize the chance of successfully corrupt/access data and/or other environment data.

To answer the question, it is a legitimate problem that can cause catastrophic failure. It is not easy/impossible to check every piece of code you just. Nowadays frameworks depend greatly on plugins, extensions and libraries. Opensource does not equal fast security fixes, but we may assume the more people use something, the faster bugs are reported and fixed. Put systems in place to limit the possibilities when it does go wrong. Have a disaster plan, design for failure, use (audit)logs, have daemons crawl the accesslogs and so on. When it comes to backdoor, people often seem to forget the outgoing firewall.


Is it safe to upload & scan personal files on VirusTotal?

Paid subscribes to virustotal can download files uploaded by others. If you consider this still safe for your users depends on what you consider safe.

See also their Privacy Policy which clearly says:

  Information we share
  When you submit a file to VirusTotal for scanning, we may store it and
  share it with the anti-malware and security industry ... Files, URLs, comments and any other content submitted to or shared within VirusTotal may also be included in premium private services offered by VirusTotal  to the anti malware and ICT security industry

Still, I think that your idea of offering a simpler access to a useful service directly from the mail client makes sense. I would though recommend that you add an easy to understand but not easy to ignore warning about the privacy implications before the user uploads a file. And it might be less invasive to first check if the hash already exists at VT before uploading a file (and not upload if hash is known to VT).
Ideally you also make it easy for users to remove an accidentally shared file (thanks to @Mirsad for this suggestion in a comment).


Using Google Search results to determine password strength

There is plenty of research on which passwords are "popular."  You can find a lot of it here: https://xato.net/passwords/more-top-worst-passwords/

You have no way of knowing what Google does with queries.  It is almost certain that such queries are logged, and are associated with the originating IP address.  That would mean Google has a list of the passwords you tested.  That list could be misused by a Google employee, and might be subject to search warrant, subpoena, discovery, or some other legal demand: https://www.aclu.org/blog/technology-and-liberty-national-security/how-private-your-online-search-history

If I were Google, I'd be looking into search terms that produce no hits; that's how they write the rules that let them do their magic.  So, your practice is likely to come to the attention of Google researchers.

Finally, to address whether there is an easy attack, password attackers first try word lists of various sizes, then go for brute force and heuristic attacks.  Short passwords not on any list or in Google's indices will fall to brute force.  Longer passwords may fall to heuristics.  Ars Technica did a series of articles on this.  The most relevant is here: http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

Give it up.


How do I configure nmap to verify my firewall is performing stateful packet inspection?

The flag for SYN ACK scans is -sA. scanning all ports is -p- 192.168.0.0/28 will scan for the obvious subnet. You may want -vv to see more details

The following command:

nmap -sA -p- 192.168.0.0/28 -vv

should work.


Should I expose AWS Credentials on github?

Apart from this being a bad idea in general (see comments on question), also a bad idea because aws will restrict your account once they find out.

Resolution process is time intensive and plenty of work as you need to change all credentials on your account, no matter the permissions of the leaked creds :)


Read this article: https://linuxhint.com/lxd-vs-docker/

It seems there is no other more secure than the other. Everything well configured has similar security level, but Docker seems more secure "by default". I mean, on Docker by default a container is not accessible from outside by default, ping or ifconfig are unavailable from inside a Docker container. Of course you can enable all or configure whatever to work in the same way as LXD.


Not really but preferably you have at least one part in it which is random (unless for instance when you need roaming. Another reason is that WPA uses the SSID as salt for the hash. This means that rainbow table exists if you have a on often used SSID (i.e. linksys)
Yes correctly. It's security through obscurity (but it can be useful). Attackers will generally send deauth packages on all channels in the hopes that a client is connected and will start broadcasting the SSID.

For your scenario it depends, to discover a hidden SSID you need to have at least one client connected to try and discover the SSID. So it depends, he might switch between attacks (depending on his goal).


Are non-personal AD users a security risk?

You need to distinguish between two types of non-personal account:

Generic accounts are accounts that multiple humans can login to. These are generally bad as you lose accountability. If John and Fred both have access, and a malicious event occurs, who do we blame - John or Fred?
Service accounts are used by applications, not by humans. Provided these are configured so a human cannot use them (which generally means tightly controlling the password) then these are not a major security risk.


How does the Samba misconfigured '/etc/passwd' file security bypass vulnerability work?

I think that the following quote explains the vulnerability best:

  A flaw was discovered in the way Samba handled users without a home directory set in the back-end password database (e.g. "/etc/passwd"). If a share for the home directory of such a user was created (e.g. using the automated "[homes]" share), any user able to access that share could see the whole file system, possibly bypassing intended access restrictions.

So it's not authentication that is bypassed here. It's just that the authenticated user will see the entire file system, not just his home share. Note that access will still be subject to file and directory permissions.


Is Wiki software a good idea for Disaster Recovery Plans?

Any documentation software will work just fine, even a bare web page can do what you hope a wiki could.

But, there is one aspect that you need to keep in mind: an authoritative version. Having a wiki means interative versioning, but that's also its weakness. How can the organization have faith that in the middle of a disaster that they are using the tested, approved, and safe version of the plan? What if a disaster occurs while you are in the middle of updating the wiki? What if an attacker maliciously updates the plan to his advantage and then triggers a disaster?

Depending on how you implement it, you need to make sure that only the official version of the plan is available. That's certainly possible, but you need to make sure that you implement the wiki in a way that accounts for that.


Security considerations for managing internal network from an external website

You are basically managing your network through Google. You define settings on Google's account page, and on boot the router pulls settings from them. This allows for example easy migration to a new/replacement router, as it just pulls the latest configuration on boot.

Because we're talking about Google I assume they've done their homework as far as securing the data in transit between your computer and their systems, and your router. I would expect everything to happen over HTTPS, so it is secure in transit.

Data storage on their systems should be secure as well, but if it isn't then you've got much bigger problems than your router configuration being accessible - your entire Google account would be at risk, including GMail, etc. So personally assuming you're fine with Google controlling your router and having access to your network, you shouldn't have anything to worry about.


Can anyone see my files on the same network?

Accessing your wifi network does not automatically give anyone access to your computer or any other device on your network. Your devices are protected by their own passwords.
They might be able to attack and break your computer and gain that kind of access, but your computer would need a weakness and someone would have to exploit it.
If you want to share your WiFi, a lot of wifi routers have a "guest" network that you can set up, and they can't even see your home devices.


Block OS fingerprinting without using iptables?

OS fingerprinting also detects OS depending implementation specifics in network responses. A simply port block will not work. For these specific topic an application proxy with a different OS could make your Windows PC invisible.


Which graphic image formats contain revision history?  Does the image editing software being used matter?

Layers and history are not the same thing.

PDF is a vector format. Picture elements are geometric figures which are to be "painted" successively in a precise order, so that newer figures hide parts of older ones. This is not per se a trace of how the image was edited, only an artefact of the way things are drawn in PDF. It is not equivalent to typing Ctrl-Z on a Word document to perform some "undo" commands. But it still means that in the scenario you allude to (trying to "black out" some part of the picture), the naive editor may believe that he destroyed the information while he merely hid it.

(Anecdote: I did have, at some point, the job of "anonymizing" PostScript documents submitted by researchers in a review process. The submission guidelines specified quite clearly that manuscripts were not allowed to include any identifying element, but the grasp of mundane realities by researchers being what it is, quite a few of the manuscripts featured the name and institution address of the author. The solution involved adding an extra white rectangle over the offending area and editing the image so that the author name read as a bunch of 'X' even if the rectangle was removed.)

In bitmap formats, the picture is made of elementary pixels which are juxtaposed, and which do not hide each other. When you modify a bitmap picture by applying a black rectangle on them, the colour previously held by the pixels is forgotten, not merely hidden. There are a few bitmap formats which handle "layers" and thus could potentially have the issue you evoke (depending on how the black painting is done), but the common bitmap formats (including JPEG, PNG, BMP and GIF) do not have layers, and when you paint some pixels in black, information is gone for good.

With the GIMP, a free wannabe replacement for Photoshop, you can see the image layers, and when you save to a format which does not support multiple layers, you get an explicit warning that layers have to be "merged" -- which means that hidden pixels are eradicated.


As a user, how can I defend myself from disclosed unpatched zero-day vulnerabilities?

The answer is to take responsibility for your own security.

If you rely only on software vendors for your security your trust is arguably misplaced and you might be disappointed quite often.

You are in control of your system as an individual and it is therefore your responsibility to take the necessary measures to protect what is important to you. Most software vendors care very little for you cat picture collection.

It all comes down to knowing what is on your system, how you use it, how important it is to you and how you can minimize exposure. The reputation of a software vendor is a great guide to knowing how much trust you should place in a piece of their software.

Based on your personal risk assessment you can employ basic secure "best practices" like disabling Flash in your browser by default and only enabling it when absolutely necessary, or better yet, removing it completely. If possible, you can also stop using the software completely as another answer suggested. If you want to take it one step further you can also have a default deny policy for javascript in your browser to prevent unwanted malicious script for running (I do this - it's a lot of effort but I sleep better at night). Don't click on email links. Review which ports you have exposed to the internet. Trust with reluctance ... and so on and so forth.

Having said this, you should know that  even if you do all of these things you can only ever make an effort to minimize exposure and will never be immune to 0-day as even the most trustworthy software can be vulnerable in some way, and when this day comes it is your queue to reevaluate your risk and adjust your behavior and mitigation accordingly.

Remember: "The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and I'm
not even too sure about that one" - Dennis Huges, FBI.

Edit: I forgot to mention a very important and relevant concept that ties in with some of the points made before. In order to mitigate the potential effects of a 0-day vulnerability in any particular piece of software you can make sure that in your environment you adhere to the the principle of least privilege. By constraining the privileges of the software you inherently limit the privileges of the the exploit*.

*Assuming the exploit does not make use of a privilege escalation vulnerability.


OpenVPN and running other services on same server

One issue is that if there are any services which are only accessible from the server's IP, including services accessible from the LAN (like your router's admin page) or even other services running locally on the server which are only accessible to localhost, then a user successfully logged into the VPN may be able to access them.

If you have any services like this (like your router's admin page) that you don't want VPN users to be able to access, then make sure they're securely protected by passwords and don't just rely on the inability of outsiders to connect to them.


How to prevent a hacker from accessing other user's web dir

You're probably too late for the server as it stands now - there are a number of different ways an attacker could conceal ways back into your system, so your safest course of action is to consider that they've got access, have copied any data on the system that they wanted to, and are free to upload anything they want to to any website on the server. Either restore to a recent system backup (not just site files), then work on securing it, or take a copy of the site files, wipe and rebuild server, then upload site files after manually checking each one individually. Might seem a lot of work, but any other option leave you open to getting attacked again.

There are several ways to prevent attackers from being able to access more than one site despite them being hosted on the same server - you could look at virtual containers (where each site effectively runs on a separate server) or implementing strong access control levels (so if a specific user account is breached, they can only write to files within their designated folders) - it very much depends on your requirements though. Bear in mind that in most cases, files must be readable by the web server user in order for them to be served, so if an attacker has control of that user, they'll be able to read anything within the website folders - if that is a problem, you need to look at OS level separation through something like Docker, although the configuration for a containerised setup is more complex than Apache/nginx virtual hosts.


Input validation: how to do it if I must accept HTML as part of my input?

By definition, the FHIR is asking you to preserve the XSS vulnerability of the data (store as code, display as code). XSS requires that the data be displayed back to users, which could be prevented with output validation, instead. Accept the input, store as JSON, filter when displaying the HTML data as HTML code. Depending on the "output" systems, this could be much easier (it depends on the need of the system).

Filtering out specifically bad code (malicious javascript, links, etc.) is going to be very difficult. There are lots of ways to hide bad code through obfuscation.

What you could do, depending on the details of the FHIR specification, is to whitelist good/acceptable code. If the FHIR spec is tightly defined, whitelisting should be easy to perform. If the spec is not tightly defined, it might be impossible to block all attempts at stored XSS.


I think it is some type of inverse spam filter poisoning. They are sending mails which seems not to be spam (and contains none of their viagra etc. marketing).

The bayesian spam filters are checking the distribution of words to categorize mails.

After they sent out a lot of mails containing only their "words", and classified as not-spam, they could use these words to seem their spam as normal mails as well.

I am thinking about a secondary trick:

This mail contains images, and nothing really spammy, only some trash. Google doesn't show mails by default, but you can click a "show images" or like button to show them. If you do this, the images will be downloaded from their external site. If the image url contains some type of identification string, on the server side will be shown, which users opened the mails really. This information helps the spammers to better organize their targets (they could find the last people on the world who until now opens spam).


Are there any known vulnerabilities in PPTP VPNs when configured properly?

Yes. The protocol itself is no longer secure, as cracking the initial MS-CHAPv2 authentication can be reduced to the difficulty of cracking a single DES 56-bit key, which with current computers can be brute-forced in a very short time (making a strong password largely irrelevant to the security of PPTP as the entire 56-bit keyspace can be searched within practical time constraints).

The attacker can do a MITM to capture the handshake (and any PPTP traffic after that), do an offline crack of the handshake and derive the RC4 key. Then, the attacker will be able to decrypt and analyse the traffic carried in the PPTP VPN. PPTP does not provide forward secrecy, so just cracking one PPTP session is sufficient to crack all previous PPTP sessions using the same credentials.

Additionally, PPTP provides weak protection to the integrity of the data being tunneled. The RC4 cipher, while providing encryption, does not verify the integrity of the data as it is not an Authenticated Encryption with Associated Data (AEAD) cipher. PPTP also doesn't do additional integrity checks on its traffic (such as HMAC), and is hence vulnerable to bit-flipping attacks, ie. the attacker can modify PPTP packets with little possibility of detection. Various discovered attacks on the RC4 cipher (such as the Royal Holloway attack) make RC4 a bad choice for securing large amounts of transmitted data, and VPNs are a prime candidate for such attacks as they by nature usually transmit sensitive and large amounts of data.

If you want to, you can actually try cracking a PPTP session yourself. For a Wi-Fi user, it involves ARP poisoning your target such that the target sends the MSCHAPv2 handshake through you (which you can capture with Wireshark or any other packet capture tool). You can then crack the handshake with tools like Chap2Asleap, or if you have a few hundred dollars to spare submit the captured handshake to online cracking services. The recovered username, hash, password and encryption keys can then be used to impersonate logins to the VPN as that user, or to retroactively decrypt the target's traffic. Obviously, please do not do this without proper authorisation and outside a controlled environment.

In short, please avoid using PPTP where possible.

For more information, see http://www.computerworld.com/s/article/9229757/Tools_released_at_Defcon_can_crack_widely_used_PPTP_encryption_in_under_a_day and How can I tell if a PPTP tunnel is secure?.

Issues discovered with RC4 (resulting in real world security issues in protocols like TLS) can be found in
http://www.isg.rhul.ac.uk/tls/RC4mustdie.html and https://www.rc4nomore.com/

For the cracking portion, refer to
https://www.rastating.com/cracking-pptp-ms-chapv2-with-chapcrack-cloudcracker/ and https://samsclass.info/124/proj14/p10-pptp.htm.


Is AES 128 encryption weak for very small payload size?

Since AES is a block cipher with 128-bit blocks, it can, by definition, process only a 128-bit entry. To turn it into a system that can encrypt and decrypt messages of arbitrary length, then you need to use a mode of operation. Each mode has its own requirements. Most will require an IV which MUST NOT be reused (if you encrypted several messages with the same key, each message needs its own specific IV), and some modes have extra requirements (e.g. in CBC, it is crucial that the IV are selected randomly, uniformly, and in a way that cannot predicted by whoever chooses the data to encrypt).

Some modes also require "padding" in case the input message length is not appropriate in some way. Some modes can process input data of arbitrary length (e.g. CTR), while others need the data to have a length that is a multiple of the block length (e.g. CBC).

Most attack models that warrant encryption may easily be turned into active attack models, in which the attacker not only wants to inspect the data, but he also may modify the data. Thus, whenever you use encryption, you normally need integrity as well. Combining encryption and a MAC is a non-trivial task, so using a mode which combines both features is highly recommended. The most standard mode that combines encryption and MAC safely is, as of early 2016, GCM.

If you do everything correctly, then there is no additional issue with the input data being short. Short data is common in, e.g., SSH connections.

Note, though, that while encryption protects the data contents, it tends to leak the data length. Depending on the kind of data that you are sending, its length might reveal a lot of information to outsiders.

Don't use random padding. Random padding cannot be checked at the decryption side, because it can be anything. Random padding gives extra power to active attackers (in SSL/TLS, see the POODLE attack, which leverages random padding in SSL 3.0). Instead, if padding is necessary, use a deterministic padding that the receiver can check. A mode that does not require padding is preferable, because it is easier to process it correctly on the decrypting side (i.e. without leaking information when an invalid message is sent).

Summary: use GCM.


I'd love to hear about more Infosec Audiobooks/Podcasts. I think Risky Business is great and allways on the pulse of what's current. I personally like their sense of humor although it's not for everyone.

Ghost in the Wires is pretty entertaining.

I had a look through Audible a few weeks back for educational infosec books but couldn't find much. I guess that anything with block of code or diagrams doesn't work so well as audio.


Security of SPF vs SPF and DKIM in email

What benefit would DKIM provide if SPF is already used?

If a domain has SPF configured the receiving mail server can check if the claimed sender of the mail according to the SMTP dialog (i.e. MAIL FROM) is allowed to send mail from this IP address. This helps against sender spoofing only a bit since only the sender based on the SMTP dialog is checked but not the From header of the mail. But mail clients usually care only about the latter one.

With DKIM the outgoing mail server signs a mail and this signature can also be checked by the sender, i.e. not only by the receiving SMTP server. This signature might include the whole body but might also be include only part of the body. And while the From header is part of this signature it does not mean that the From header must be from the signers domain which means spoofing is still possible.

Spoofing of From is only addressed by configuring a DMARC policy which requires that the domain in the From header is either protected by SPF or DKIM and which specifies a policy when the requirement is not met.

  Is it correct to say that SPF ensures that the server from which the email claim to originate is the one from which it in fact originated and DKIM ensures that the content of the email message hasn't been modified?

E-mails don't claim to be from a specific server but from a specific domain. And like I said both SPF and DKIM alone don't protect against spoofing the From header. And DKIM only protects part of the mail against modification: usually it protects the full body but might be configured to allow extending the body. And it only protects some headers but not all.

  If it's correct that DKIM protects the message from being tampered with, then from whom does it protect exactly? Who can alter the content of the email while in transit, what are the common attack vectors? Can there be a malicious "node" that relays the email but modifies its content?

Mail is delivered hop by hop and even if it is encrypted with TLS this only is relevant between the hops. So there are many parties involved which have access to the unprotected mail and could modify it.

  Would it be possible for an attacker to make a server that relays emails and then snoop on them or modify the content, just like anybody can make a malicious Tor node?

If the attacker can spoof DNS MX records which specify how a mail gets delivered or if the attacker can intercept the mail on unprotected transport or at one of the hops the attacker can modify it. But the attacker cannot simply put a server on the internet and declare it to be the responsible server for the domain, he must other parties convince that they send the mail through this server (i.e. spoofing DNS MX record).

  If the email provider I use supports sending emails over SSL and I want to send an email to my friend who uses Gmail (which also supports SSL), does my message travels the whole path encrypted? Does it mean that the message is encrypted with a public key belonging to Gmail and no server which relays the message will ever see it unencrypted?

The messages travels encrypted from your mail client to the mail server of your provider, is decrypted there, modified (Received header added, maybe DKIM header) and the re-encrypted again to transport it to the next hop which might be google already or might be another upstream mail server.

  Let's assume that I use SPF. An attacker attempts to sends an email that appears to come from me. Where is this email relayed to (is this something called MTA)? Does it work like a node that forwards information to further nodes? If the attacker controls the first "node", can't he report to the nodes that it forwards to, that the message passes SPF when it does not and the nodes that get forwarded the message would believe it?

While the attacker can add a Received-SPF header to the mail and thus claim the it did check for SPF a mail server (MTA) on the edge between internet and intranet receiving this mail might check again from which IP address the mail really comes, i.e. it will not trust the Received-SPF header. This header is mainly used by spam checkers which want to incorporate the result of the SPF test into their reputation check but don't run at the mail server and thus don't have access to the original IP of the sender.


Is there a security risk in hosting an app's HTML/JavaScript payment system on a CDN?

Your CDN will likely use HTTPS to serve the assets, so if the app is configured correctly (requiring HTTPS with trusted certificate), DNS hijacking/spoofing and other similar malice should at most result in a DoS.

You can use subresource integrity to check the hash of JavaScript files on the client to make sure they match a known good, so any modifications will prevent it from being loaded:

<script src="https://example.com/example-framework.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>


Risks of serving untrusted content under HTTP Content-Type: text/plain?

Some very badly broken browsers (notably old IE versions) try to "snif" the "true" content-type and will act as if the content-type was text/html.
Perhaps you can try to blacklist said browsers, either according to user-agent or by providing HTML as text and checking if the browser runs JavaScript in text/plain.
If you want the browser to save the file instead of display it, try Content-Disposition (f.ex. Content-Disposition: Attachment; filename=example.txt).
IE8 Security
You can also use the X-Content-Type-Options: nosniff IE-specific HTTP header in order to prevent MIME-sniffing of text/plain HTTP resources.

Sites hosting untrusted content can use the nosniff directive to
ensure that text/plain files are not sniffed to anything else.


There's not really enough information in your list (as hard as that is to believe, with 12 steps and all) to properly answer, but as you mentioned in your comment above - this is pretty close to the StackExchange model.

With that in mind; have you considered running your own OpenID Provider? The protocol spec looks pretty close to what you're after. This is also a well-tested model, so a lot of the concerns have already been well-solved. OAuth may be suitable, but it's designed around limited access tokens - don't know enough about what you're doing to say which is more appropriate.

Coming back to your model - what you've specified looks ok, though as written there's a mix of 'model' stuff and 'implementation' stuff that makes it a bit tricky to analyse. You're relying on the referrer, but it looks like in this scenario, faking the referrer will only log a client in to a different site they would have access to anyway. You are depending on referer though - maybe just load the frame with a GET request including the referrer?

You're also relying on the ability to pass info back and forth between frames; you may want to consider using an interim page on auth.com instead (i.e. forward user to auth.com, if user already logged in there, POST back to https://B.com with 1TT). Using iframes complicates things (What if you're already in a frame? You're relying on the browser here to 'break out' successfully - could this be subverted by messing with the DOM?). You may be able to make this secure, but it's a complicating factor - and the enemy of good security tends to be overly-complicated schemes.


I've not yet discovered any tools to detect/clean devices infected with xcodeghost but as far as the remediation goes for cleansing BYODs that are infected with malware, make sure to check the BYOD policy first of course!  If it's stated in your policy that wiping a user's personal device is a possibility then I see no reason not to use that option.  It's pretty much the most efficient way of ensuring the malware is 'gone'.  Well, aside from banning their device from the network.  Whether that's physically banning the device from the work site, MAC filtering, blacklisting on routers/firewalls etc.


Can wifi administrator see data transfer over android phone. precisely gmail app communication

Yes, your data is not protected by default and can be intercepted by people that administer the WIFI and other devices that transfer data on the network.

The encoding you are talking about is SSL. SSL enabled websites will protect your data from being read by attackers that can control the communication channel (WIFI, ethernet cable, ISP). Here is a good description of how SSL works.

For the data that is not protected by SSL, you can use the technology called VPN. This would encrypt and protect all your communication from being intercepted by attackers. Here are 7 free VPN services.


Session Hijacking - regenerate session ID

I've seen implementations that tried this approach and ended up pulling it because yes it can cause resource issues and race conditions across Web farms.  It sounds like a good idea at first, but can also make your application more prone to denial of service attacks if the regeneration process is too cryptographically intensive.  Answer there is to pregenerate session IDs periodically and keep a cache available, but then you have to manage the cache securely.

Some more common solutions to securing session ID variables is to

use SSL
only generate the authenticated session ID after successful login over SSL, else you become vulnerable to session fixation
generate cryptographically random and unguessable tokens
expire session IDs frequently
properly expire then server-side on log out
mark the session ID cookie as HttpOnly and 'secure'


MD5 is not encryption, it is hashing. Not the same thing at all.

Otherwise, congratulations ! Whoever sends that to you is proposing marriage:

$ printf "You will be my wife one day" | md5sum
1ce67f05968d51656eb71f13368f0b2d  -

(Take care before answering "yes": he looks like a big nerd.)

Edit: the interesting part is of course how I found the source. I just looked it up on Google. The Web + Google makes for a rather good table of precomputed hash values.


Sanitize computer after Homeland Security seizure

Given that your laptop was in possession of a government entity with unknown intentions towards you for an extended duration, there's really no way you can restore it to a fully trustworthy state.

If you assume the U.S. DHS to be hostile, then the only secure process to move forward with includes:

Assume all data on the laptop, and all other confiscated hardware, to be compromised.

Change all passwords for accounts which may have been stored/cached on the devices.
Change all passwords for other accounts which use the same password as the accounts which may have been stored/cached on the devices.
Void all payment mechanisms which may have been stored/cached on the devices.
Communicate appropriate privacy warnings to potentially-affected third parties.

Assume the laptop, and all other confiscated hardware, was modified to allow future collection of data, or control of the system, by U.S. DHS or related agencies.

Destroy the devices. Do not capture any backup images or copy any files. Just burn/shred/pulverize/crush them as-is.
Purchase replacement hardware/software from a trusted source, through a trustworthy supply chain, and re-build from scratch.
If trustworthy backups exist (backups which were not also confiscated, and would not be remotely accessible with credentials that may have been stored/cached on confiscated devices), restore data from those sources as needed.

Anything short of this leaves open several extremely undesirable possibilities:

U.S. DHS may continue to have access to your online accounts and/or financial resources.
One or more of your devices may have persistent malware which allows U.S. DHS, or related agencies, to spy on you or control your systems. And you're back to #1.
Files stored on one of your devices may have malware which will install itself upon opening. Then see #2.
Hardware or firmware on one of your devices may have been modified to include malware, which may install itself upon connection to another device. See #2 again.
Any software projects you were working on, and/or the tools you use to compile them, may have been modified to include malware. Back to #2 again, and also add further impact to your customers if it's not discovered and dealt with before distribution.

You should check out the 10 Immutable Laws of Security. Law #3 certainly applies. Assuming they've exploited that law, you can probably bet Laws #1 & #2 also apply.

  Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
  Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
  Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore

Also check out the 10 Immutable Laws of Security Administration. Here, Law #4 is most apropos.

  Law #4: It doesn't do much good to install security fixes on a computer that was never secured to begin with


Sanitizing USB memory stick by overwriting dummy data

Short answer is no. This will not guarantee that nothing can be recovered. Simply because the method is slightly crude and would require some miracle for the data you write to drive to match the drive's size itself. Even one file "sexytalkwithmywife.txt" and "bankdetailsforthepast10years.pdf" can be in the span of kB, and you may miss those sectors regardless of how many times you write.

Standard Methods

for windows there are various utilities like this one which will do complete data erasure for drives.

for linux the standard for a long time has been shred, where you would first run fdisk -l and lsblk to figure out exactly which drive you are supposed to wipe (important step, many a cry have happened because people didnt do this) then to do something like this:

shred –vfz –n 6 /dev/sdX

where -vfz is, in order, please tell me how far along you are continually, please dont bother me with permissions, please write zeros on the last pass. n is the number of times to write random data to each bit. and sdX is the drive you identified in the previous step.

Recent Developments

The last i heard the community was still a wash with how to handle this for memory and ssd's since they apply load balancing and trimm support as you say. Kingston came out with a suite of tools for the specific data erasure of these kinds of hardware called Secure Erase, See their article here. But some people (myself included) do not like the idea of a software that specifies only one manufacturer and to my knowledge isn't open source.

Here's the issue, there's no main standard for this yet. Most manufacturers of ssds have applications in firmware that can be called upon for wiping data properly in these devices, which doesn't make things very easy for us. Most of us dont want to go searching around hardware specs to figure out how to do this properly per each individual drive. Unless I've missed more recent developments (a possibility in this area) we may just have to wait for better options for ssd's and the like to be absolutely sure. But for now, i doubt you are dealing with the kind of threats that shred or eraser cant handle.


Is the newly adopted NFC technology going to be safe?

NFC is just another medium like wires, wifi, microwave, light-comms, etc. It will be incumbent on the security professionals to create and guide their safe use whether it is for payments, data sharing or any other purpose.

Being an invisible medium probably brings its own risks in terms of awareness, but there is nothing intrinsic beyond its invisibility that suggests it will be any more or less secure as a medium.

As for your scenarios, I don't think the medium is relevant, only the systems that use the medium and they will depend on secure design, architecture and implementation like any other.

People have been talking about this issue for some time now in a security context and awareness is definitely growing.


Security risks of file shares vs ssh or sftp, in "backward" direction?

The real question is how does ransom ware spread. This might seem counter intuitive, but over the last two decades there have been numerous problems with SMB that have resulted in worms, ransomware, and all kinds of crazy stuff taking down networks of interconnected systems. Your logic might be right (that your workstation can push data to the server, but the server cannot push data to the workstation), but there are other things.

You don't have to map a drive to a drive letter to connect to a remote host. //server-name/path/to/folder is another technique. Then it's all about the permissions, the other shares.

If you were to turn off network ports on the firewall to block SMB, and you were to turn off all the shares, you could finally kill SMB file sharing. That would be fantastic.

But you'd need a way to share files. SSH is an authenticated mechanism that doesn't necessarily rely on active directory and there are not 20+ years of backwards compatibility baked into it. Oh, i forgot to motion that a current windows system can still communicate with a windows system from 20 years ago, and in there lies a ton of potential bugs and weird configuration settings that might leave your network fairly insecure.

It might be time to stop updating the databases, turn off SMB, and install SSH on the systems instead. It's a valid path forward.


In general, flask-admin is not different to any other web app and you need to follow general application security guidelines. The OWASP Top 10 is a good introduction and there are more detailed guides too.

If you've written your own controller code it could be vulnerable to flaws like SQL injection.

To configure flask-admin securely, enable CSRF protection

Make sure you have detailed logging of actions within the admin area, which include application layer actions not just HTTP logs, and are connected to user IDs.

Securing authentication is important. You could consider using MFA, and possibly IP restricting admin access. In addition to password hashing, you want a decent lockout policy, password strength checks, and to ensure your forgotten password process doesn't undermine this.


What are you saying when you sign a PGP key?

OpenPGP does not define any rules for certifications

From RFC 4880, Signature Types:

  [...] Please
     note that the vagueness of these meanings is not a flaw, but a
     feature of the system.  Because OpenPGP places final authority for
     validity upon the receiver of a signature, it may be that one
     signer's casual act might be more rigorous than some other
     authority's positive act. [...]

Informal best practices

There is a kind of informal best practices, though. By posting a certification of undefined or casual trust level (sig or sig2, signature types 0x10 and 0x12) you declare to be sure of the signee's identity. This might have happened by checking official documents, or knowing somebody very well. Often, people send an encrypted mail containing the signature as attachment to also verify ownership of the mail address.

Certifications of positive trust level (sig3, type 0x13) usually claim some advanced certainty of the signer in what he's doing. This might be because of long-time knowledge of the signee, or high confidency in well-known documents presented (for example, passports of your own country).

Certification policies

As there are no general, enforced rules for certifications, some people post certification policies, which they claim to follow. They often just represent the informal best practice, but can help others at justifying your certification statements.

These often contain information on how you verify keys, what documents you require, how you handle variations in signee's names, and possisbly more. Often, they're signed documents, and referenced from each certification issued GnuPG's cert-policy-url option.


What could an attacker do if they gained access to PBKDF2 hashes?

The attacker would have to crack the hashes in order to obtain the original passwords. Since PBKDF2 does multiple iterations of the same hash function, the act of cracking them would be significantly slower. The end result is that even weaker passwords are less likely be revealed, leading to a significantly lower percentage of successfully cracked passwords in the credential list.


Is it bad practice to share password hashes between systems?

The issue with this design is that there are now multiple points of failure.  A compromise of the database for application A now compromises the security of application B.  You also have more transport security to worry about.  An attacker can theoretically get a MITM for the password copy from application A to application B.  A traditionally designed application does not suffer from this flaw.


Is flashing an OpenGApps package over Cyanogen secure?

Due to the apps being closed source, there's no way to inspect these files myself that I am aware of.

I'm pretty sure that you did not inspect Cyanogenmod source code or checked if the provided ROM for your platform matches the source code available. You've probably also did not check the firmware of the device which is usually only available as binary too and is actually the source of security problems.

This means that downloading GApps from a widely published source is probably as risky as what you did before. Yes, these files could contain malware but the chance is low since lots of others use these files and did not notice anything more malicious than the expected privacy problems with these apps. But of course someone could have recently compromised the download server and exchanged the downloads like done in case of other trusted sources.

But at the end you should trust your device only as much as you trust all parties which were involved in building and distributing it. This not only includes custom ROM's and apps but but also hardware (which is not this hard anymore, i.e. often software too). And this is not only true for your phone but also for your computer, router, internet provider, car ...


Does Sweet32 work on services that do not use web sessions/cookies (such as FTP)?

Sweet32 does not specifically attack authentication but it tries to extract secrets contained in kind of structured, partly known and very large data. Authentication information in the HTTP header fit this description if it is possible to send lots of HTTP requests over the same TLS connection. But depending on the kind, amount and sensivity of data you transfer with FTP this can be a problem for FTP too.


How insecure is it to publish my direct EC2 URL?

I'd be fairly certain that AWS is being scanned constantly by attackers, so running a webserver on port 80 shouldn't be considered a secret.  This is true in general for any publicly available service.

25 years ago people hooked up services on dialup modems with little or no security (default passwords).  They believed that the obscurity of the phone number was enough to protect them if they didn't publish the phone number, unaware of wardialers that had existed since the early 80s, the name stemming from the 1983 movie Wargames.

This sort of practice is called security through obscurity, and has been highly frowned upon for decades.  Essentially if you think you're safe because nobody will visit an IP address unless they're explicitly told about it, think again.


Yes, they are secure. The known_hosts will protect you from a Man-in-The-Middle attack by checking the remote servers fingerprint (assuming you have not deactivated this check), and the communication is encrypted using an algorithm such as AES128 (may vary).

The fingerprint check serves as a proof that the server still possesses the private/public key pair from when the host was listed as a known_host. Without the private key it is not possible for an attacker (MiTM) to forge the fingerprint and pass this check. This check only works, of course, if you can guarantee that you were connected to the right host when it was listed as known, and not to a man-in-the-middle.


Using a single number instead of an IP address or a DNS name, which are concrete uses?

Depends on the filter implementation and maybe the OS on the client machine.

As you said - the IP address will end up in the TCP packets in its binary representation, regardless of how it was originally passed to the socket software layer. Firewalls will filter for this binary address and thus catch anything - there is no way around that.

However, if the "firewall" or "proxy" is run on the machine subject to the blocking (e.g. on an employees machine instead of the company firewall), i see a way this would work:

If the "IP-Filter" is implemented as a sort of delegation-replacement for the OSes networking library (e.g. Windows Firewall / Windows Defender). When software asks for a new socket to Host XY it will check XY against a blacklist. If not blacklisted, it will pass the API-call on to the OS.
If that filter software does not take the single-number representation into account, it will allow connections to blacklisted hosts.

P.S.: I think this scenario is rather obscure. I cannot imagine that a serious sysadmin would rely on Windows Firewall or sth. similar. Also, think Windows Firewall uses a whitelists (remember these "Allow Software ABC to access the network XYZ?" dialouges?)


If a firewall deletes DOS packets before they reach the designated application. Is it then possible to break trough the firewall with a DDOS attack?

Some firewalls have the option to bypass inspection on high load, i.e. Checkpoint has the option "To bypass IPS inspection under heavy load". Which means if this options is set you could weaken the security using some kind of DOS attack (not necessarily all kind of DOS) which ultimately could lead to security problems.

If no such options is set most firewalls will just slow down and impact traffic this way. This by itself does not directly affect the security but it might be used to hide the real attack in all the log data or to divert the attention from the administrators to the DOS and away from other attacks.


Is it a possible vulnerability / GDPR violation if basic profile of users are enumerable through the URL?

From GDPR PII Definition:

  ‘personal data’ means any information relating to an identified or
  identifiable natural person (‘data subject’); an identifiable natural
  person is one who can be identified, directly or indirectly, in
  particular by reference to an identifier such as a name, an
  identification number, location data, an online identifier or to one
  or more factors specific to the physical, physiological, genetic,
  mental, economic, cultural or social identity of that natural person;

Which means, that you should create some kind of notification, that will notify a user that the data he is submitting to the website are publicly accessible. If not, then you violated GDPR.


MAC filtering is not a part of the 802.11 spec, and is instead shoved into wireless routers by (most) vendors.  The reason why it's not a part of the 802.11 spec is because it provides no true security (via kerckhoff's principle).

In order for wireless to work, MAC addresses are exchanged in plaintext (Regardless of whether you're using WEP, WPA, WPA2, or an OPEN AP).  For encrypted wireless, the MAC address is either a part of the initial handshake (used to derive the session key), and/or exposed during pre-encryption communications.  In addition to all of these reasons, MAC filtering is also much more of a pain in the butt to upkeep than instituting something like WPA2-PSK.

Simply put, MAC filtering is not something that needs to be "cracked."  In open networks, people simply only need to sniff the air and they will be able to see what devices are working, and then they can use one of many, many extremely simple tools to change their MAC address.  In encrypted networks, they will need to sniff and grab a new handshake (which can easily be forced via a deauth attack).  From there, they have access to your network.

My suggestion is to use WPA2-PSK with a strong key for personal networks or WPA2-Enterprise with a strong EAP mode (PEAP or TLS) for enterprise networks.  The main difference between the two of these, aside from the method of authentication and authorization, is that with WPA2-PSK, if someone knows the PSK and can capture the handshake of a user, they can decrypt their stream.  That is not possible with WPA2-Enterprise, because it uses EAP, which has a different encryption key per individual via the EAP mode.  This is important because you wouldn't want just anybody with access to the network to be able to decrypt the CEO's wireless communications.

It is also important to note that with WPA2-PSK, your ESSID does play a part in the security of your network because of the following:

  DK = PBKDF2(HMAC−SHA1, passphrase, essid, 4096, 256)

Essentially, WPA2-PSK uses your ESSID as the salt when running PBKDF2.  For this reason, you should also attempt to keep your ESSID unique, to avoid attacks using rainbow tables.

In summation
 - MAC filtering does not provide any level of "true" security
 - Use WPA2-PSK if possible (Most smartphones do support it)
 - Try to have a unique ESSID


EMV cards, is the PIN always stored also at the issuer secure server side?

There’s 3 types of cardholder verification methods (at least when I was playing with EMV 3 years back)

PIN (both offline and online)
Signature
No verification (this is possible under some circumstances).

Note these verification methods are used only for physical transactions or ‘card present’ scenarios.

For PIN transactions there’s two flavors, and Offline PIN and an Online PIN.

Online PIN is straightforward, it’s when a PIN is verified by the issuer in an online transaction. Online here means the card terminal has connectivity to the issuer and has sent the transaction and PIN onto the issuer for verification.

For online PIN, obviously the issuer has the PIN -- otherwise it wouldn't be able to verify it.

For offline PIN, the PIN isn’t sent over the wire, but rather sent to the chip on the card, and the chip then verifies the PIN directly, providing the response back to the terminal.

In this case it is possible that the issuer wouldn’t know the PIN as it is stored on the chip. But, I’m guessing an issuer must be able to reissue a PIN to the customer should the customer forget it, hence somewhere deep in their data center lies a server or HSM that knows it :)

Whether or not your card supports Online PIN or Offline PIN (or both) depends on the issuer and country of issue. But I Guess in both situations an issuer will have the PIN, regardless of type.

Now reading more into the question, just because the issuer has the PIN doesn’t mean it’s going to be easy to retrieve. This isn’t something a call center agent will be able access. It’s probably locked down tightly and only retrievable via printing a PIN mailer (printed letter to the customer) or some other highly secure method.

I'm not sure what the true objective of your question is, but hopefully this answers it.


Security onion sounds like your best bet.  It will set up and IDS pretty fast.  Have it watch traffic in and out of your network and install OSSEC on your clients at your house and point them to security onion.  This website has all the information you need on the howto.
http://securityonion.blogspot.com/


Are JWT's the way to go in my situation?

JWTs are meant for when your login process is separated from your application, possibly even offered by another company. OpenID Connect is a single-sign on solution that uses JWTs.

However, in your situation, everything seems to be under your control. It currently runs on one server, but even if it needs to scale to 100 servers all those servers would have the same role and you would still control them.

I would advice using sessions. Sessions are well supported by all frameworks. They are easy to reason about, unlike JWTs which can fail in unexpected ways. Sessions are also easy to scale to 100 servers, so that is not an advantage unique to JWTs.


How does SQL injection work through URL?

The point of SQL injection is to modify the query where the variable is.

Let's use the query you wrote as an example. If the variable id contains something like this and isn't sanitized properly:

' OR 1=1#

It would return every single row because it has been modified to this:

SELECT * FROM `mytable` WHERE id='' OR 1=1#'

The trick to avoid the syntax error is to comment the rest of the query (The character # does it in this situation.


Is the windows root trust store used by IE?

IE uses the Windows root trust list.  It's not compiled into the kernel, per se, but it's installed into the SYSTEM registry hive.

It also does not have any means of updating the stored trust list independently.

Update 2017-07-16: Per http://netsekure.org/2011/04/automatic-ca-root-certificate-updates-on-windows/ , Internet Explorer's reliance on CryptoAPI (which calls into components with privileged access) means that CryptoAPI can and does update roots, on at least some versions of Windows.

(And if you disable Windows Update and have no other patch management procedure, you're going to have a Bad Time.)


Are there any signs for an end-user of cellular calls being routed through a Stingray device?

On Android Devices you can monitor all cellular Towers you are connected to with AIMSICD (https://github.com/CellularPrivacy/Android-IMSI-Catcher-Detector/wiki) so if you connect to an unknown cellular Tower (an attacker) in an area where it already knows the "good" cellular towers the device normaly connects to it warns you.

Quoting the github Page:

  AIMSICD attempts to detect IMSI-Catchers through detection methods such as these:

  Check Tower Information Consistency
  Check LAC/Cell ID Consistency
  Check Neighboring Cell Info
  Prevent silent app installations
  Monitor Signal Strength
  Detect silent SMS
  Detect FemtoCells


«Secret ballot» requirement for a distributed e-voting system

That approach wouldn't work, since when the secret key is published, whoever did vote what, would still be available.

If you want to provide a simple voting system, its better that eligible voters, are given a key by you. This key are generated in a such fashion that it can be verified that its a valid voting key and not a key home-generated by some rogue user.

One thing to accomplish this, is that a random private key (Elliptic Curve) is generated. This generated key, call it Kr, is converted to a public key (EC), Pr. After this, you MAC Pr with a secret key, Ks, eg MAC(Pr, Ks) = V. V is a hash, that should contain a secret validation string Vs. This string (Vs) should be same for all votes, but kept a secret.
If the result of MAC does not contain the specified validation string, then a new private key is generated. (eg, Think "brute-forcing" until a private key that has the valid verification value appears, Think "vanitygen" in bitcoin. A malicious party cannot do this since he does not know the MAC key or what the result substring should be.)

Eg, in other Words, Generate a secret key Kr, such as the MAC of the corresponding public key combined with a secret MAC key, gives a hash result, which contain a specific secret substring.

Repeat this until enough secret keys are generated so theres one secret key for each voter.

When time for voting, after a successful secure voting identification, give the voter one of the random secret keys. Check off the voter in a list, eg so he cannot check out multiple secret keys. This can be done online.

Voter votes by signing the vote and publishing this in the public ledger.
Since the public key cannot be linked to a voter, its not possible to link votes to voters.

First (valid) vote is what Counts, and when the voter has voted, he is encouraged to publish his key, possible anonymously, and/or display it for friends. The reason for doing this, is to prevent a key to be linked to a voter post-vote, which prevents coercion. This also prevents the voter from proving what he voted for, to someone, because he could just have taken some other's key to prove he voted "right" (when he actually voted "wrong").

Actually, the voter can generate his own fake key, and the publish a fake vote, that will not be counted, using this fake key, and then use that fake vote to "prove" he voted "right" to a coercier. The coercier cannot detect that the vote is fake Before the authorities publish the Ks and Vs.

However, the publishement must be delayed so all the nodes have recorded the vote Before publishing the key. Of course the voter must check that a couple of random nodes have recorded the vote correctly. The reason for this, is that if the vote is withheld by one or more malicious nodes, they can change the vote using the published key. By delaying the publishing of the key until the nodes have published the vote, its not possible to change the vote after that.

When voting are over, the authorities publish the secret MAC key (Ks) and the secret validation substring (Vs).

Anyone can now tally the votes using the public records. The first valid vote (invalid vote could be voting "what?" in a yes/no vote) of each key that succeeds MAC validation with Ks and Vs, is a valid vote. Any other votes are ignored, eg double votes or "home-generated" keys. Nobody can cheat the voting system.
If the number of valid votes exceed the number of eligible voters, fake votes have inserted, either by a malicious party that "accidentially" created a valid key by chance, or a malicious state inserting votes in the system.

Such fake votes should not be reacted upon unless theres a Close call, eg there is a possibility that the fake votes affected the outcome. A "yes/no" vote where the result is 90% yes, such vote is not gonna affect the outcome unless more than about 40 % of the votes are fake.


NSFW Website loaded on home network then open at work

It really depends on what perimeter security your employer has. As you stated there is nothing on your laptop so the only way that the employer could catch this is if there is a firewall or other device at the perimeter tracking all traffic.

If there is such a device it will likely record how much traffic you passed between your machine and that site. This gives you some leverage. You can explain to your employer the situation and the tiny amount of data passed will back that up.

All that being said, it is highly unlikely your scenario triggered any alarms with your security team and I would not worry about it.


Possibility of business calls/leads being professionally stolen?

In a situation like this, you don't know what attack vector is being used, but it seems that you may have some anecdotal evidence from customers?

The best solution is to log all occurrences and then attempt to determine the threat(attack) vector. You may have to reach out to the companies that provide your phone service or the client's. This is very dependent on how the attack takes place, considering multiple client's are potentially vulnerable with an unknown breach. Once you have a log of what user's are doing, and what results they are getting, you can quickly identify what companies are doing it and can, with the help of ISP's or phone companies, determine where the attacks are coming from.

You can start by testing using google voice numbers or track phones you activate and call or attempt to contact yourself with.

I would also invest in a VPN service and turn off location services while you do this so that an attacker might not know that you are the one making the calls if they have you blacklisted for the malware.

Once you have even a small record of where the attack is coming from, you can begin to figure out how it is happening. Vague suspicion isn't enough to figure out what is actually happening.

The more specific the threat, the more specific the solution will be.