How can I stop this attack on my router?

This is very likely not a Denial of Service attack. As a matter of fact, this looks very much like a SYN Port Scan. Someone (very likely automated, by an infected machine) is attempting to scan your machine. They send a SYN packet to you on a certain port, then your machine responds with an ACK packet.

There's no real danger here. This is the Internet; someone will always try to scan your machine and try to infect you. Outside of books and in real life, nobody really is going to DoS your home router. Your router is already doing a good job by detecting and DROPing those packets.

My advice: Forget about this, and move on with your life.


How do I know the remote server is genuine the first time I connect with SSH?

Connect to the server using the administration console from the control panel of the provider, generate the server SSH keys, save the fingerprint. When you connect to it by SSH later, compare the fingerprint with the one you saved before.

But the chances of someone spying on you specifically to intercept and change the fingerprint of your recently commissioned are pretty small.


Current browsers all do SNI (Server Name Indication) to make it possible to setup different hostnames on the same IP but with different certificates. To make this work the hostname of the target server is included in clear in the initial handshake packet from the client (ClientHello).

By selectively blocking the ClientHello if it contains specific strings inside the SNI extension a firewall could block specific SSL sites, even without affecting other SSL sites behind the same IP. On less capable firewalls (without deeper inspection) you could simply have broader rules to block access to specific IPs.

Because this is SSL and the firewall has no access to the real certificate it cannot send the client a proper error page, so the client just gets strange error message inside the browser because the connection was either reset or it times out, depending on how the firewalls handles the blocking.


Without further analysis it is hard to determine the exact cause of this. One common issue is that running the application under a debugger changes the memory layout slightly and can be enough to break the exploit with/without a debugger attached. Have you tried running it without a debugger attached and then analysing the core dump?

However pop edx;ret shouldn't be overly difficult to find, either at another address or through a slightly longer gadget such as pop edx; pop eax; ret. Putting together a ROP chain is a puzzle and there is more than one way to do it.


It may be that you need to narrow the scope a little in order to get started.

Which aspect of security are you interested in. From the list of standards, you seem more interested in application security & especially in authentication and authorisation?

That would be a much easier set of targets to learn at least to begin with.

Also, you may need to be aware of regional and sector differences in security requirements. Banking, health, US vs EU and so on. Each have important differences.

Having decided on a more focused approach, perhaps you could update the question to get some more specific advice?


Your understanding is mostly correct. Using Bitlocker in TPM-only mode (not the same as just "without PIN" because you could use another form of authentication, such as an external key on a USB device) means the disk encryption key will only be available if the OS boots up normally; if the boot process is modified by malicious code, or if the normal OS isn't booting at all (because you're booting to Linux or something instead) then the TPM won't reveal the key.

Bitlocker, in any mode, doesn't really "transform the normal Windows User login into something secure", except in the sense that you can't easily attempt offline cracking of the (weak) password hash the way you normally can. In fact, in TPM-only mode, it is vital that you have a strong Windows password on all login-enabled accounts, because the attacker can still attempt online brute-forcing of that password (though Windows will limit how fast they can try). However, it does mean that simply getting the hard disk without the rest of the machine will be useless to an attacker, and that getting the entire machine but with no idea what the login passwords are and no special attack hardware will be nearly as bad. On the other hand, even without Bitlocker, an attacker could encrypt data that is protected with a key derived from their login password (using DPAPI and/or EFS) and therefore require the attacker to get their login password (although in that case brute-forcing the NTLM hash is probably the easiest option, and with BitLocker you can't do that).

Note that there are limitations of TPM-only Bitlocker. For one thing, it's much easier to bypass using a hardware attack, such as freezing the RAM (once the encryption key is retrieved from the TPM) and physically removing it from the running system, then using external hardware to read the key out. TPM-only mode is also incompatible with any kind of intentional modification of the boot process, so any time the user (or OS) wants to install a patch that modifies the bootloader or similar, it must briefly "disable" Bitlocker by writing a clear-text key to the disk. This key is removed after successful reboot, but it provides a window where an attacker could bypass Bitlocker entirely. Finally, "TPM-only" Bitlocker still usually has a "recovery key" that the user is told to store somewhere; if the attacker gets that then they can bypass Bitlocker regardless of the other protections used.


The Anti-Phishing Working Group (APWG) has statistics about how long it takes, after notification (e.g., through MarkMonitor or similar), for a dead-drop site (e.g., malware or botnet C2) to go down. Take it with a grain of salt though, the APWG tracks criminal actors, but nation-state actors have been found to keep their C2 running for 4-5 years, perhaps even longer.

http://docs.apwg.org/solutions.html
http://docs.apwg.org/ipc.html
http://docs.apwg.org/resources.html

Some payloads do not utilize standard, IPv4-based communications (some common examples include Address Routing Protocol covert channels or even SMB named pipes) -- and some payloads have no network communications (not even RF or speaker-based) at all because they are programmed to do damage (or degrade systems, deny access, et al) as logic bombs.


Finding/Predicting BotNet Generated Domains Without DGA Knowledge

All of your three ideas are not applicable:

Exclude Dictionary Word Domains

There are DGAs that use dictionary word domains, for example matsnu

Include Seeming Random/Garbage/Arbitrarily Large Domain Names

There are absolutely legitimate domain names that have been generated by an DGA, especially in this time of "serverless" hosting with ephemeral domain names.

Cross Check DNS information for possible registration information etc.

There is not way to tell legitimate and illegitimate customers of domain registrars that offer anonymity.

There is however a GitHub repository that collects outputs from various DGAs to try and use machine learning for recognition of plausible and probable malicious DGA generated domains.


Push notification - can I use any mobile auth application?

As far as I can see from the respective websites those apps are specific to one service.

I am not aware of a generic "push" protocol. So if you want to get that form of push notification from a service you will have to install the matching app.


How secure is this php code against SQL injection?

Is the above code vulnerable to any kinds (error,blind,union based) of SQL injection?

No, but only because sha1() happens by luck to produce output that never contains any SQL metacharacters.

Your query-creating code should not need to know about that implementation detail. It should be escaping the $password_hash as well, so that the line of code works on its own, and can be verified as correct and safe without having to look at the wider context. Otherwise, when you change how that $password_hash is calculated (say, to store a more secure salted hash), you may find that you've just created a vulnerability in that query code. Creating unnecessary coupling between disparate bits of code, potentially in different files, is in general a bad idea.

  If the above code is safe, why do people still go for Prepared Statements etc...?

Because prepared statements are typically easier to read, understand and verify; it is harder to accidentally omit an escape. Compare:

$query = "SELECT id,username FROM users WHERE username = '"
         .mysqli_real_escape_string($link, $username)
         ."' AND password ='"
         .mysqli_real_escape_string($link, $password_hash)
         ."'";

with:

$query = $mysqli->prepare('SELECT id,username FROM users WHERE username=? AND password=?')
$query->bind_param('ss', $username, $password_hash);

Although I'm not a huge fan of mysqli's particular brand of parameterised queries (especially binding to variables instead of values), the latter still seems simpler and more maintainable to me.


Sent emails can be deleted from the "Sent Mail" easily as part of a script. So that part is feasible.

Forwarding rules are meant for users to change, so there is no function to 'hide' a rule.

More likely that someone is logging into your account. Change your password and use 2FA on your account.


In a monitored network, can the admins tell if Tor is being used?

According to scuzzy-delta, yes:

  It is possible to detect that someone on your network is using Tor (e.g. You're a network administrator at a workplace, and an employee is using it), and the fact that you're using it is in itself interesting information.

His answer:
https://security.stackexchange.com/a/27848/76663

Using a bridged TOR connection is a safer bet but by no means the definition of safe, closer to gambling actually. The reason for this is they are meant to circumvent cencorship, if one bridge doesn't work for you in e.g. Iran you try another until you find one that's not blocked yet. However, I assume all bridged connections will work in lands of freedom, and therefore you have no idea what bridge connections your admin is aware of.

Diving deeper, this is an excerpt from https://www.torproject.org/docs/bridges.html.en

  Over the last few years, censors have found ways to block Tor even when clients are using bridges. They usually do this by installing special boxes at ISPs that peek into network traffic and detect Tor; when Tor is detected they block the traffic flow.
  To circumvent such sophisticated censorship Tor introduced pluggable transports. These transports manipulate all Tor traffic between the client and its first hop such that it is not identifiable as a Tor connection. If the censor can't decide if the connection is a Tor connection, then they are less likely to block it.

If anyone can pitch in on the missing piece, is "obfs3, scramblesuit, fte, and obfs4" ample obfuscation then?


Running an Open Server (contents are visible)

Assuming your server doesn't use any credentials besides system-level accounts and the MySQL password, there's one thing you need to protect: the swap file.  Programs are supposed to take steps to prevent credentials from winding up in swap, but they don't always do so.

There are some sensitive things in /dev and /proc (such as /dev/mem and /proc/kcore).  The proc filesystem driver should prevent you from making dangerous changes to /proc, but in a udev-based system /dev has no such protections, so don't change anything there.

Keep in mind that giving read access to everything means users have read access to the MySQL database by inspecting the files directly.  Make sure any web applications you install don't store credentials (user or application) there.


Is my computer at risk of being hacked when using public Wi-Fi?

Maybe.  The question is not whether there is a possibility that someone might be able to hack into your computer; the answer to that question is always yes, it might be possible.  If you are connected to a network, we can't rule out the possibility that someone might be able to attack you.  Rather, the right question is, how big is the risk?

In your case, if you use good security practices, the risk is pretty modest.  Good security practices are things like turning on automatic updates to keep all programs updated with the latest security patches, using anti-virus, using a firewall (should be enabled by default on Windows 7), and not visiting any site that requires a login over public Wi-Fi.
Not especially risky.  It sounds like your practices are relatively safe.

The biggest risk has to do with visiting Stack Overflow: because you are using a public Wi-Fi network, and because Stack Overflow does not use SSL (HTTPS), if someone there were malicious, they could steal your Stack Overflow login credentials and take control of your Stack Overflow account.  They might not be able to learn your Stack Overflow password, if you never type it into your browser while using public Wi-Fi, but they could still learn the authentication cookie that's stored in your user and that's used to log you in.  At that point, once they have the authentication cookie, they have control of your Stack Overflow account.

However, this risk is relatively modest, because it's just your Stack Overflow account, and let's be honest, it's probably not the end of the world if someone steals your Stack Overflow account.  The Stack Overflow folks know about this security risk, and they've been asked to adopt HTTPS to mitigate this risk, but they have declined to adopt HTTPS because they consider the risk to be of low-severity and they consider Stack Overflow accounts to be not important enough to be worth worrying about very much.


wireless security - Authentication and Association

WPA and WEP have little in common security wise. WPA does not allow Open System Authentication nor Shared Key Access. You cannot be authenticated and not connected to an access point. You associate, then you authenticate.

There's a decent answer to a similar question here: https://security.stackexchange.com/a/160365/200347

Please note that whist WEP and WPA clients use the same passphrase to authenticate to the AP, in the WPA case this is used to negotiate per-client (rotating) encryption keys, whereas on a WEP system, every client uses the same encryption key.


How can I make a strong password that's easy to remember? Is the 4 Word method safe?

The main problem with passwords is not password complexity, but password reuse (obligatory xkcd). One service leaks logins and passwords, suddenly lots of providers see a surge on account hijacks. Why? Because we humans cannot remember dozens of different passwords, so we create one password for common services, and one for special ones. But most of us will have only one password.

Don't create your own passwords, use a password manager. They can create very complex passwords, one for each service, have plugins and extensions for the major browsers, have strong encryption, cloud backup, multi device syncing, and more. Don't trust your brain to create different random passwords for each service.

Using a password manager means you will only need to know one password - the master one. This password can be written down and kept on your wallet. All the others will be created by the manager, and can contain 128 chars, 10 numbers, 30 special chars, including ĥaŕd-tö-tỹpẽ ones...


Minimum access required to access LSA Secrets

You can dump lassas direcly from task manager or use procdump,in this case you are a local administrator on machine but you have not full admin token,i.e task manager is not running as administrator on windows 7 and you did not invoke UAC (consent.exe),then you can use mimikatz to grab LSA secrets.Use this link it is useful https://forums.hak5.org/index.php?/topic/29657-payload-ducky-script-using-mimikatz-to-dump-passwords-from-memory/


Certificate Based Authentication with AD and 802.1x or EAP-TLS

Maybe some of following statement are not accurate, but in overall, it works very similarly.

It really depends on implementation. But the idea is the private key never leaves the device it is using it. If so it is wrong design. I don't know any MDM (mobile device management software) as I didn't work with any previously but it will work in very similar way as I describe bellow.

The mobile device (iPhone in your case) will generate private key. It will also create the CSR (certificate signing request - it out of other data includes public part of the generated key), please note the CSR can also be generated by the MDM then delivered to iPhone for signing. Then iPhone signs it (hashes it and encrypts the hash) using the generated private key and send it over the MDM to CA (certification authority) for validation and approval. MDM is responsible for device authentication before the first key is generated, I would say you need to login using AD user name/password for the first time from trusted network without any authentication method, such as 802.1x.

Once the CA will ensure the validity of CSR (this can be also completely manual process) it creates the certificate and signs the certificate using its private key. It stores generated certificate to issued certificates store and passes it back to the MDM. MDM will store it in AD (or not) and send it back to the iPhone device. Once device receives the signed certificate it checks if it has appropriate CSR stored inside (it should as it generated / signed it), pairs the information from signed cert and CSR together and store the certificate including the public and private parts of the key internally (usually to secure certificate store). Private key can be additionally protected using some kind of another protection (i.e. PIN, password, smart card, whatever) so it user mus authorize usage of the key in such case. In iPhone I would say it is protected and encrypted using the user password/pin/fingerprint so once you unlock the phone it can be used.

For authentication, (it does not matter if it is 802.1x EAP-TLS or another TLS or another method using certificates for authentication - everything works similary) you use this certificate signed with CA and usually something signed (encrypted) by your private key related to the certificate. It is usually some kind of challenge sent by the server and it is used to proof you own the private key related to the certificate you sent to server to be used for authentication and you claim it is yours.

Server then checks your certificate (if it is valid - date/time, if it is not revoked, if it is supposed to be used to do the action you are actually trying to do and if it is signed with trustworthy certification authority) then it uses the public part of the key stored in the certificate to decrypt the challenge to make sure you are owner of the certificate (the correct private key was used to sign the data) If the decryption is successful and the challenge matches the challenge sent to you for signing it actually means you are the owner of the certificate and you own the private key related to that certificate.

So what the server needs to know to authenticate you? Just the root CA or immediate CA authority certificate used to sign your certificate, your certificate including your public part of the key and the data encrypted (signed) with your private key related to the certificate. That's enough to authenticate and authorize you. It never needs to know your private key so there is no reason to store it in AD or in CA or wherever else than in your device.

Few words about the AD and MS PKI (CA service) - its same as stated above :):

AD never stores your certificate including private key. Why? Because it simply does not know it. It never did. If you ask for certificate in MS PKI (others work in the same or very similar way - EJBCA, OpenCA...) it usually works in the way you generate the private key on your computer, then you create certificate signing request. This can be done at any place, in case of MS it is on the CA server self service usually. CSR contains i.e.: distinguished name (name or email), your address, what purposes you request the certificate for - ie. authentication, email signing, whatever). Then you get the CSR, and you add some info to it, i.e. public part of the key, fingerprints, whatever. Finally, you sign the CSR (you hash the CSR and you encrypt the hash using your private key) then you send it to the self CA service portal. CA then generates a cert, signs it and delivers it back to you in pre-defined way. I.e. by placing it on the web or by email or, it probably could be integrated with MDM also.

In this case I am not 100% sure the described process works like this in detail but it will be very very close to it.


How to secure a public device against abuse?

Stick a little button on the tower itself, which also has to be pressed in order to open the flap.

Plate #1 from my pending patent application.


Copyright James Daniel Marrs Ritchey. This material was created for
  submission at
  'What are Security Considerations of Using File Upload/Comparison as Simplified Second Factor?',
  but can also be alternatively obtained from
  'https://snippetly.blogspot.com/2020/05/pros-and-cons-of-using-file-for-2fa.html'
  under the terms of any of the following licenses: Ritchey Permissive
  License v8
  (https://jamesdanielmarrsritchey.blogspot.com/2020/01/ritchey-permissive-license-v8.html),
  The MIT License (https://opensource.org/licenses/MIT).

All security measures are a balancing act between various client-side, and server-side attack vectors. By increasing the security against one vector you decrease security somewhere else. Whether it's a good or bad configuration depends on your service and clients, because that's what decides where you need to prioritize your protection.

Positive:

The file is essentially acting as a secondary password, but assuming it's a decent sized file, created using a secure method (eg: a 10 second video of my dog), it would be significantly more secure than a normal secondary password (eg: 12-18 printable characters) against login attacks, or stolen password database attacks. So this increases some server-side security. Since the user isn't typing it in, it won't be catchable by keyloggers running on the device, or persons/surveillance watching the user login, which increases some client-side security.

Negative:

This file must be present on the device, and it can't be protected with file encryption since it's being directly uploaded. The same situation applies to SMS codes. A normal secondary password however, can be stored in a password manager.
To avoid loss of the file users may decide to backup it up (eg: external drive, cloud, etc). This results in additional attack vectors which you are counting on the user to have the know-how to protect.
The user may be enticed to name it something obvious to more easily remember which file to use (eg: "2FA.jpeg"), but this will also make it easier for hackers/malicious software to find it.
Uploading files will use more of the user's internet bandwidth. This could deter cellular, and satellite users from using your service.
Matching the uploaded file with the record on your server will use more of your storage, internet bandwidth, cpu usage, and memory usage which may affect your cost of operation.
You will likely wish to impose maximum size restrictions, but non-technical users may not know how to best make a file under that limit (eg: You impose a limit of 3MB, but their camera produces images which are 10MB).
When the file is uploaded it will be temporarily stored on your server without file encryption, unless you hash it client side, but hashing it client-side would affect the performance of the user's device.
Unlike an SMS code which comes through a different route of communication than the username and password, all communication of login credentials will be coming through one line of communication.
Unlike SMS codes which are usually one-time use, this file will be used every time, which means once an attacker has it they have it.
Depending on the data provided to the user from your service, this file may cause a noticeable change in data transmission (eg: spike, or drop) between the client and the server making it possible to track when a user is logging in vs using the service.


How does KEEPASS store images, videos and attached documents/items?

Keepass 2.0 file attachment security

Already answered via Xander

  File attachments are stored encrypted in the database (like all other database content). http://keepass.info/help/v2/entry.html


What are the dangers of hot-linking assets from other websites

Including resources from a third party site means that you include resources in your page where you have no control about the content of the resource. Thus, even if the content was the expected one at the time you've added the link it can change whenever it suites the owner of the site - or somebody which hacked the site. This is not restricted to a redirect as you envision but the third party site can serve a different content in the first place.

The impact of this depends on what kind of resources you hotlink. If you include JavaScript from a third party site (like done a lot when offering the ability to share on social media) then the third party can essentially fully control what gets displayed to the visitor of your site but also embed a keylogger in your page or similar. Including fonts might be a problem too since malicious fonts could be used multiple times in the past to use bugs in the browser or OS and execute malware.

And while replacing images will usually not result in unwanted code execution (unless another bug in image processing is exploited) you can get instead an image you don't actually want on your site. For example some sites punish unwanted hotlinking with "special" images but it might also be more harmful be used for phishing attacks as seen in this answer. See also this question for more ideas.

Note that the replaced resource still needs to match the expected type of resource. This means if the browser expects a font and the attacker serves a JavaScript file instead it will not be executed. But if the attacker serves a malicious font in this case it will be used.

For some types of resources and for some browsers subresource integrity will help to detect if third party resources gets changed and not load the resource in this case. But, this currently works mainly with script and css and for example not with fonts or images. And, it  works currently only with Chrome, Opera, Firefox and Safari.


Is there a way to identify the host of a malicious VM from across the network?

You don't say why you would care whether the attacker is using a VM.  I'd say it is irrelevant.  It's just a distraction.  So I'd unask that part of the question.

As for how to tell what machine on the network is the host system, your ability to do this in this special situation is about as good as the situation when there is no VM.  You have DHCP and ARP logs to go by.  If you can identify the IP address, go to your Ethernet switch and find which physical port that IP address is connected to -- then have a nice stroll to that port and have at it.  Don't forget to bring your clue stick.


Company VPN (tunnelblick), https, root CA and privacy

tunnelblick seems like a simple p2p VPN that establishes a secure connection.
However if all your traffic is routed through the organizations' DC rather than split tunnel configuration they might have a web gateway acting as a MITM. You can relatively easily check this by checking the certificate of common websites you use. If it's the original certificate there's probably no MITM.


Is a TPM which boots a full-disk-encrypted computer to login secure?

In my opinion, this makes the Full-Disk-Encryption as secure as the Windows login screen, which is a considerable downgrade.

Yes. And in a sanely configured, domain joined, patched, laptop, this is fairly secure.

As the disk is encrypted, you can not bypass the login my editing configuration files easily. You can not decrypt the disk if the TPM refuses to unseal, which it should refuse if boot options has changed.

It will reduce security over having to enter a pass code on boot. It will also increase convenience and probably reduce number of support calls. It will for sure thwart opportunistic thieves, that find or steal a laptop without any aim, from discovering the content.

You will have to balance this against who and what you protect. An answer applicable to the budget spreadsheet of Moms & Pop Cornerstore LTD may not be applicable to the engineering drawings of Boeing - to take two extreme examples.


Differing scrambling parameter generation methods in Secure Remote Protocol

The original article also states that: "For example, both sides can compute u as a simple function of B", which is what occurs in RFC 2945. u could be generated randomly and also transmitted, but deriving u from B (which is already transmitted) is harmless (security wise) and saves a few bytes (which is always good).


SSLv3 cannot be disabled, can I use weak cipher as a workaround?

There are secure non-POODLE-vulnerable ciphers which you can use with SSLv3 - POODLE only impacts variants with CBC.  The RC4 ciphers, for example, are not vulnerable to POODLE.  Now, RC4 is a tricky thing.  It's considered breakable (but not really actively broken), but since it's the best workaround for things like BEAST and POODLE, it's heavily used and probably secure enough for some small window of time ahead.

Since you're going to upgrade lighttpd anyway, RC4 should be fine until you get that done :)


Going to host a "hidden service", should I "wipe" or edit file metadata?

If your goal is anonymity then yes. But bear in mind that Tor, using a layered encryption scheme through a number of network, is considerably slower than single layer encryption using a direct connection. Transferring large files slows down the network for all users using the same circuit.

Note that each user that connects to your hidden service uses a different circuit meaning that if you have a lot of users connecting at the same time, downloading large media files the impact can be detrimental to a large subset of the network.

Consequently, some nodes may block others in order to improve availability.


Where can I practice MITM raw binary protocols?

Burp suite is by far one of the best tools to learn about http protocols and it can also help you in MITMing attacks.


What Gmail features should be Opted-Out to prevent PII from being indexed?

Social Security / tax numbers should never ever ever be sent by e-mail in plaintext. It doesn't matter if the E-mail is sent via SSL/TLS, you cannot guarantee that an e-mail will remain encrypted throughout it's life. (You can almost guarantee that it won't be)

I don't know what "personally identifying information" really means, but absolutely no information that could be use for identity theft should be included in an e-mail.

No CC numbers.
No SSN/TID.
No "security question" answers. (mother's maiden name and the likes)
Driver's license number
etc.

If you absolutely must send this information by e-mail it should be in an encrypted attachment.


What are a few good lists of threats to use to kick-off conversations with others about what worries them?

Loss of revenue is the only threat you really need to talk about with business people. Frame the issue in terms of money and emphasize that money will be lost if security is not given a high priority. Explain that money can be lost in the following ways:

Lawsuits due to disclosing sensitive
user information.
Bad publicity, which damages the
brand, which, in turn, results in
revenue loss.
Unsecured checkout processes open up
the avenue for lawsuits and also
reduce sales.
A non-functioning website reflects
poorly on the business, hurts
conversions, and reduces traffic over
time.

It is better to have a risk-management approach to security to minimize the possibility of these risks occurring. In the end, it will cost less to be proactive than to be reactive.


Is it unsafe to use /etc/hosts file as a website blocker in the following manner?

Short Answer
Is it safe to use the /etc/hosts file as a website blocking "null" address?
I would argue the answer should be: No.
If for no other reason than the requests are not actually "nulled".  They are still active requests.  And as the OP indicates, since the requests are for legitimate Internet hosts, this sort of short cut method of redirecting requests to localhost may interfere with testing networking code in a development environment.
Perhaps a better method of blocking traffic to and from certain Internet hosts, is to utilize iptables which is the interface to the Linux kernel's firewall.  iptables is the default networking rule table for most GNU/Linux systems.  Some distros use ufw as a front-end to iptables.
If you want to use iptables, here's a simple script which will DROP all incoming and outgoing packets for a list of IP addresses or hostnames with one address or hostname per line contained in a plain text file called ~/blocking.txt
## Block every IP address in ~/blocking.txt
## DROP incoming packets to avoid information leak about your hosts firewall
## (HT to Conor Mancone) REJECT outgoing packets to avoid browser wait
for i in $(cat ~/blocking.txt); do
    echo "Blocking all traffic to and from $i"
    /sbin/iptables -I INPUT -s $i -j DROP
    /sbin/iptables -I OUTPUT -d $i -j REJECT
done

Sample ~/blocking.txt
websiteiwanttoblock.com
anotherone.com
ip.add.of.net/mask

Do not place your localhost IP addresses in this file.
Longer Answer
While reassigning Internet hosts to localhost in the /etc/hosts file is a common short cut technique to block unwanted Internet hosts, this method has some serious security drawbacks.
Incoming requests
Incoming requests which were not purposefully initiated via a specific user request.  The most common example is ads on webpages.  Let's follow the incoming packets...
First, I start up wireshark.  Then I place the biggest Internet ad company in my /etc/hosts file with this line:
127.0.0.1   google.com

And then disable all ad blockers in my browser, navigate to youtube and play any random video.
If I filter my packets, broadly including Google's IP address space:
ip.addr==172.217.0.0/16

I am still receiving packets from Google.
What does this mean?
It means that there is a possibility of a malicious server inserting malware which may be able to attack my computing platform via packets that are still arriving and sent to localhost.  The use of /etc/hosts rather than dropping or rejecting the packets via the firewall rules, is a poor security measure.  It does not block incoming packets from possible malicious hosts, nor does it provide effective feedback for trouble shooting purposes.
Outgoing requests
Outgoing requests which are sent to localhost rather than being rejected or dropped by the firwall rules are still being processed by the kernel.  There are a few undesirable actions that occur when /etc/hosts is used rather than the firewall:

Extra processing is occurring when the outgoing packet hits localhost.  For example, if a webserver is running on the host, the packet sent to localhost may be processed by the webserver.

The feedback from outgoing requests may become confusing if the /etc/hosts is populated with certain domains.

iptables can handle lots of rules
According to some:
ServerFault: How many rules can iptables support
A possible theoretical limit on a 32-bit machine is 38 million rules.  However, as noted in the referenced post, as the iptables rule list expands so does the needed kernel memory.


Getting called from hidden caller ID, what are the dangers if I answer?

If you do not say anything, then the only danger is that the caller knows that the number is live. But that does not seem to be a big risk since they appear to think it is live anyway.

Just answer but say nothing except "who is this please?" then put the phone on mute to help you resist the temptation to say anything. Phone scammers are experts in playing on people's emotions to get them to engage. The trick for you is to not say anything except to ask questions. Do not give any information but turn every one of their questions back into a question. It might seem childish and rude, but it's effective.

There are lots of legitimate reasons for legitimate companies to call you while hiding their number. If you find out that it is legitimate, then you should be able to go to the official website to get a number where you can call them back on. Aim to do that.

If it is not legitimate, then call your phone provider to get the calls blocked.


Is using Git for deploying a bad practice?

I would go as far as considering using git for deployment very good practice.

The two problems you listed has very little to do with using git for deployment itself. Substitute .git/ for the config file containing database passwords and you have the same problem. If I have read access to your web root, I have read access to whatever is contained in it. This is a server hardening issue that you have to discuss with your system administration.

git offers some very attractive advantages when it comes to security.

You can enforce a system for deploying to production. I would even configure a post-receive hook to automatically deploy to production whenever a commit to master is made. I am assuming of course, a workflow similar to git flow.
git makes it extremely easy to rollback the code deployed on production to a previous version if a security issue is raised. This can be helpful in blocking access to mission-critical security flaws that you need time to fix properly.
You can enforce a system where your developers have to sign the commits they make. This can help in tracing who deployed what to production if a deliberate security flaw is  found.


What is the difference between an HTTPS traffic setup with Stunnel and a SSL-VPN

In all evidence, the two tunnels are not equal. Given that the port and (envelope) protocol are the same, the difference might be in either the endpoints, the access rules or the certificate setup.

Unless you shut down the stunnel server (and you say nothing to that effect), you shouldn't have been able to test Adito at all. Unless the stunnel server and the Adito server are running on separate hosts, and in that case, they might well have different firewall access rules.

Another possibility is that stunnel is compiled with TCP wrappers (or through [x]inetd) and the host unable to connect to it is not allowed to connect, while Adito has no such restrictions. So Adito works, and stunnel doesn't.

What are the symptoms of stunnel's connection failing (both at client and in the server logs, if any)?


How to avoid storing plaintext during CHAP authentication

The CHAP authentication schemes requires both client and server to share a common plain text secret. However, the secret never enters the network.

So it is the responsibility of the client and server to ensure the confidentiality of the password.

The article you link is saying that password should not be stored encrypted as it does not add any additional layer of security, unless you have some specific needs for it to be encrypted (company policy, regulation, ...). The fact that CHAP cannot use a password which have been encrypted makes the encryption void anyway.


What makes an Android application vulnerable to Directory Traversal?

The generic answer for "is my code vulnerable to directory traversal?" is to ask yourself if your code:

Uses filename strings that you got from an untrusted source to read/write files on disk? "Untrusted sources" could be direct user input, things you read from files (which could have been tampered with), or from 3rd party code that your code interacts with.
If you answered 'yes' to (1), then what happens if instead of "filename.txt", you enter the string "../someOtherDir/secret.txt" (assuming this file exists)? Will the program reject it as a malicious file access, or will it happily open this file?

This kind of traversal works because unix-like environments will accept /tmp/../etc/passwds as a valid path for /etc/passwds.

Mitigation

Mitigating against Directory Traversal Attacks usually involves making sure that if you allow filenames from untrusted sources, that you restrict those file accesses to a single directory. AFAIK there's no single best way to do this, but some things to think about are:

If you are only allowing the user to specify a filename (not a folder or path) then simply reject any filename strings that contain the '/' or '\' characters. Just silently drop that request. Better is to look up the list of legal file name characters on your OS (Android in this case) and reject any string that contains a non-legal character.
If all the files that you are allowing the user access to are in /publicDir, then before you open a file with the untrusted string, make sure that the file pointed at is actually inside /publicDir. This sounds obvious, but turns out to be really tricky to get right since there are many ways to construct malicious paths, for example: "/publicDir/../etc/passwds" will fool many naive checks. So I wouldn't advise this option.

A final note is not to get into the game of "cleaning" user input, just reject it. For example, a common thing programmers like to do is to remove dangerous characters and attempt to process the request on the "cleaned" string. Don't do this. If they gave you a bad string, just reject it and let them try again. I have two reasons for this:

If the user asked you to open "../../../etc/passwd", that wasn't a typo, they didn't mean "passwd.txt", they're being an asshat. Just ignore it.
As soon as you write a function to clean strings, the game becomes to pass in a string which your cleaner with make malicious. The more complicated your string cleaner gets, the more room there is to abuse it.

So don't play the game, if it look suspicious, just reject it. I personally use mitigation option #1: rather than trying to guess which characters could be malicious, I just reject anything that contains a character other than letters, numbers, and '.'


difference between rc4-40 and rc4 in OpenSSL

From https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States:

  The export of cryptographic technology and devices from the United States was severely restricted by U.S. law until 1992, but was gradually eased until 2000; some restrictions still remain.
  […]
  In 1992, a deal between NSA and the SPA made 40-bit RC2 and RC4 encryption easily exportable using a Commodity Jurisdiction (which transferred control from the State Department to the Commerce Department).

So this is a remainder (and reminder) of those times when software was only allowed to be exported with very weak ciphers.


While working from home, is it a bad idea to give the company you work for your IP address?

This seems to be a persistent question.  IP addresses aren't secrets.  Every website you go to must know your IP address.  There's no reason to not give away your IP address.

Many companies have firewalls that only allow certain addresses through to certain ports.  This is a relatively common way of controlling access to resources with minimal effort.

However, most people don't have static IP addresses at home, and your IP address can suddenly change without notice.  So just be aware that the IP you have today might not be the IP you have tomorrow.


Can I brute-force a password hash even if I don't know the hash-algorithm used?

You question does not make a lot of sense to me. If you already know the hash and know what input generates it, what is the point of your bruteforce?

On the other hand bruteforcing something means to apply some procedure many times with different inputs and comparing the output with your hash. If you do not know what procedure to use, there is no way you will be able to apply it many times.

But if you know the input and the hash, you can bruteforce it in the beginning to find what algorithm is used. For example

sha1(i), sha1(md5(i)), md5(i) and so on trying many combinations of possible hash functions. You might guess partially what is used. So if you output is 160 bits long, you can guess that may be the last step was sha1.


Sophos Safeguard detecting content of zip files being uploaded

If the compressed file does not have a password, probably, assuming it can decompress it - there are size limitations in most products. If the archive is passworded, it is unlikely that any virus scanning software can inspect the contents.


There are two reasons why pre-filtering is done: to save on the EPS (Events Per Second) rate and to reduce the noise. Every SIEM technology has a maximum EPS analysis capability which are restricted either by the hardware or by the software license. When events exceed that limitation, the SIEM server begin to drop the packets. That is why you would only want to bring in only those events which have significant security implications.
But even more important than the EPS is to reduce the events so that your analyst(s) can analyse those events manually. Although SIEM technology can automate many event correlation activities, initially you need an analyst to go through each of the received log or traffic event manually in order to determine whether it is true positive or false positive. When you overwhelm the system with a lot of noisy events that do not have a security implication, not only are you burdening the system hardware and software resources but you are actually over burdening the analyst in analysing those events as well.
Based on my experience, you need to understand that an effective SIEM solution is the one which are analysing only security events. Many a times people want to let the SIEM analyse and co-relate many non security events as well. At times that might be useful such as correlating the system health information with the received traffic logs in case of a denial of service attacks, however, in most of the cases pre-filtering all non security logs and events and forwarding only the relevant logs to your SIEM will make the system as well as the SIEM analyst more efficient.


Is it possible to guess the length of a password by sniffing TLS packets?

All ciphers are not made equal regarding this possibility. It greatly depends whether we are dealing with a stream cipher or a block cipher.

Stream ciphers (like RC4) take a flow of n plain-text characters as input and produce a flow of n encrypted characters as output.

With such ciphers, adding a single character to the password (which acts as the plaintext data here) will make the cipher text on character longer, thus allowing a really good guess on actual password length.

Block ciphers, on the opposite, will only operate on blocks of fixed size (128 bits for AES for instance, which means 16 bytes), the last block being completed with padding.

In such case, adding a single character to the password will never make the cipher text one character longer. If it happens that the password length is long enough to fill the last block (it may require from 1 to 16 characters) then a supplementary block of cipher text will be produced, but with no mean to know how much of this new block is actually used, and therefore without any precise information about the exact password length (a 16 characters approximation does not seems reliable as long as passwords are concerned...).

Fortunately, block ciphers are the most used ciphers for common TLS applications where the data is already handled by blocks of finite length. An HTTPS request for instance has a clear begin and end and do not suffer that much from the up-to 16 bytes padding overhead caused by block ciphers. Therefore, most web servers and browsers nowadays prefer to use block ciphers than stream ones (if stream ciphers, RC4 mainly, are not disabled altogether).

Stream ciphers, having more limited cryptography properties, see their usage being restricted to very specific use-cases, mainly situations where the data appears more as a flow than well defined blocks. Network level cryptography (WPA2, IPsec for instance) are good example, but this may also affect application-level cryptography as well (VoIP application for instance can use SRTP which relies by default on AES used in stream mode). In such cases it would neither be optimal to send a whole block to carry a single effective byte nor to try to hold-on the communication in the hope that more data will come to fill the cryptographic block. A stream cipher will just follow the communication flow as it goes on.

Under some conditions, a block cipher can be used in stream mode (when used in CTR mode for instance). Most applications show a list of the enabled cipher suites in their order of preference. This cipher suites indicates the encryption algorithm used, accompanied by the operation mode whenever applicable. Here are a few cipher suite examples to make things clearer:

ECDHE-ECDSA-AES128-GCM-SHA256: This uses AES in Galois/Counter Mode (GCM), this remains a pure block cipher,
ECDHE-ECDSA-AES256-SHA: This one does not clearly show an operation mode, it is an OpenSSL notation corresponding to  the standard notation TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA assuming Cipher Block Chaining (CBC) by default, this is also a pure block cipher,
TLS_RSA_WITH_AES_128_CCM: This is a standard cipher suite showing AES used in Counter with CBC-MAC  (CCM) mode, derived from CTR it is a way to use a block cipher as a stream one,
ECDH-RSA-RC4-SHA: This one does not use AES, it uses RC4 in place which is by definition a stream cipher (while block cipher can be used as stream ones, the opposite is not true: you cannot turn a stream cipher into a block one, so there is operation mode indication for stream ciphers).

This should allow to check the kind of encryption used by your software:

When using only stream cipher, the length of the encrypted message can be easily known (so if the password length is the only variable of an otherwise known message it becomes easy to deduce the actual password length, unless the password has been hashed before being sent as Mike Ounsworth rightly outlines in his answer),
Using only block cipher will reduce this to some approximation, possibly excluding any practical use for such a small information as a password,
If you cumulate the two (for instance accessing an HTTPS (assuming block cipher) website over a WPA (stream cipher) protected Wifi network) you keep the advantage of the block cipher making the guessing a large approximation.


You're missing 2 key things here:

You need to enable full duplex arp spoofing (so the target thinks you're the router, the router thinks you're the target). Enter set arp.spoof.fullduplex true in bettercap for this.
You need to tell bettercap to sniff for traffic (assuming you're not using another tool). You can do this with net.sniff on, again in bettercap.

If that cuts off the internet for the target, make sure you've enabled IP forwarding (https://unix.stackexchange.com/questions/14056/what-is-kernel-ip-forwarding).


In general, yes, using 64-bit architectures is a bit safer.

ASLR (Address Space Layout Randomization) is a lot more effective on 64-bit architectures.  On 32-bit architectures, ASLR is not very effective.  On 32-bit architectures, it's only possible to introduce a half a dozen or a dozen or so bits of randomness into the address space layout.  This means that an attacker can defeat ASLR by simply trying many times (a few hundred or a few thousand times).

ASLR makes it harder for an attacker to exploit buffer overrun vulnerabilities, so this difference between 32-bit and 64-bit architectures has some relevance to system security.

Apart from its effects on ASLR, I'm not aware of any security benefits of a 64-bit architecture over a 32-bit architecture.


Is your PGP passphrase used to decrypt an encrypted private key, or needed in conjunction with the private key to decrypt the message?

The former.  Your PGP private key is stored on your disk in encrypted form.  In particular, it is encrypted using your passphrase.

To decrypt a file, PGP needs (1) your passphrase, and (2) the encrypted private key file; from these it can reconstitute your private key, and then decrypt the file.  Neither alone is sufficient to use an encrypted private key file.

To answer your question, your client does encrypt your private key.  It is stored on your disk in encrypted form.

(I am assuming you are using public-key encryption, not conventional encryption.)


What kind of nefarious deeds can IP address Spoofing be used for?

IP Spoofing with TCP over the open internet is impossible because of the three-way-handshake.   So you are limited to ICMP/UDP services or attacks on services available over the local LAN.  The local lan is an issue if you are able to sniff the network.  So this is a problem if you are on a broadcast network or using ARP poisoning on a switched network.  ARP poising is also a spoofed attack.

A good example of a spoofed icmp attack is the Smurf DoS Attack.  The UDP variant of this DoS attack is called the Fraggle attack.  (Who names these!?!??)  Also it should be noted that these attacks are old its unlikely that you'll find a vulnerable network.

So in conclusion IP spoofing has a very limited scope.  Because Its an attack that has been taken into consideration and its easy to prevent.


How can I securely identify mobile devices on a network without a lot of overhead?

It sounds like your real concern is at the application level. You could secure your connection via VPN; In this scenario you block access to the app from the network that is just the WiFi and require it only come from the VPN's network or other approved network. You may also consider, possibly in addition, using some type of HTTPS, TLS, etc at the transport or application layer to encrypt the connection. If you are doing financial stuff, this should have already been a requirement.

Just because you are on the network, one should not be able to just get to the app. If you were talking about getting the WPA2 password, requiring encryption at layer 3 or above can help that. If you were talking about breaking a user's application password, there should be controls in place to limit brute force attempts and to ensure complexity rules are sufficient.

If you provide more detail in your question, I will update this response.


How safe are networking ACLs based on IP-address?

IP spoofing (what you incorrectly call "hacking the IP address of the packets") isn't easy for TCP because you should also be able to receive the response even before being able to send actual application data (like an HTTP request).

IP-based restrictions should never be the only line of defense, but it's a good idea to still use it to lock down administrative accounts when you only plan to use them from the same network location; in the unfortunate event when your credentials are compromised the attacker will also need to somehow get access to that trusted location (by compromising that machine or a router in its path to your locked down system so he can appear to come from that location and receive the reply packets) to be able to use it as a pivot to log into the locked down system using those credentials


Could a password hash that's prone to more collisions provide better overall security?

The "1000" factors cancel out. By making collisions much probable so that each password has on average 999 brother passwords which equally grant access to site A, you make entering site A 1000 times easier. Due to the vast choice of possible passwords, that "easy-site-A" password has only 1/1000 probability of being good for site B (where the user reused his password), but that extra 1000 difficulty factor is over the difficulty of entering site A -- which has just been made 1000 times easier. So entry in site B has not been made harder.

One other way to see it is to imagine the attacker trying to attack site B. He then creates site A himself -- with an extremely collision-happy hash function so that every possible password grants access to A: it suffices to have a hash function which always return the same value. The attacker can certainly implement a site with no access restriction, i.e. that kind of "site A". Does it change anything to the difficulty of entering site B ? Since it is something that the attacker can build from scratch independently of site B and its users, it cannot.

In the situation you envision, you can imagine site A as a filter for site B. Sure, site A won't tell you which password is the right one for site B; but it will reduce the list of candidates to 1000 (out of a few billions). This can only help attacking site B, and will certainly not protect site B.


Yes, you need the same IV to initialize the decryption process. The purpose of the IV in CBC mode is to ensure that encrypting the same plaintext will result in a different ciphertext each time. By the way, are you encrypting it using AES or RSA?


Free second-level domain SSL certificate

StartSSL does in fact offer free SSL certs for subdomains, though they are Class 1 certificates. You just have to go through a normal domain validation on the actual subdomain. Wildcard certificates (e.g. *.example.com) are not available for free, and are only available when you purchase a Class 2 or 3 cert. I have used these free subdomain certificates on my various personal projects, and they validate in Safari, Chrome, Firefox, and IE just fine. You don't get the green status bar, but you wouldn't anyway without paying for extended validation.


Yes. Certificates are basically a public key with information about the owner attached to it. They can be signed by an certification authority to confirm that the owner information is correct. There are a number of certification authorities already present in your browser.

You get the warning if the certificate, the server shows you, is not signed by a certification authority, your browser trusts (or is invalid for other reasons).

A man in the middle will trick you to accept his own public key as server key, so that he can use his private key to decrypt everything you send to him. He will then re-encrypt the information and pass it on to the real server.

There are out of the box security solutions, that work this way to scan the https traffic for virus and sites that do not comply with the company guidelines of acceptable use. They dynamically generate keys for the servers you want to talk to and sign them with their own certification authority.

In most cases the administrator will install the certificate of the company certification authority as trusted on all company computers, so that there will be no warning.

Paying attention to the names of the certification authorities in the chain of trust is likely to reveal such systems, unless the administrator put a lot of effort into hiding it by creating different local CAs with matching names.

There are more details at Can my company see what https sites i went to?


Can just receiving or opening a spam email put my computer or emails data at risk?

The majority of the emails programs organize the messages on two formats:

All the messages in one file.
One file per message.

Is fine if you open the file message with vim, notepad or so program that don't do any parsing and potentially can execute something such as attachment, or follow a HTTP link. With any other program I will be skeptical of opening but just because I don't know what is going to do the program that opens the message with an infected body part for example.


SSL/TLS is a protocol providing an end-to-end encrypted communication between two parties each having one of the keys in private/public key pair. Typically a browser and a web server.

In normal circumstances any device between the two endpoints cannot decrypt the communication. That includes firewalls.

It is however possible (and used in organizations) to use a proxy server that decrypts and re-encrypts communication thus allowing interception and decryption (for example for monitoring and filtering). It does however require adding an additional certificate to a trusted certificate store on a client machine (either automatically through a software management system or manually by users).


Virus with PGP Encryption Preventing Virus Scan

This question is a bit off-topic, but I'll post my personal experience with a similar issue.

Create a VistaPE image.

Integrate PGP into the image (Follow this guide and download the PGP tools from here)

Burn the VistaPE image, then boot from it.

Use the following command to decrypt the disk:
pgpwde  --decrypt  --passphrase "YourPassword"  --disk 0  --all-partitions

Note: I'm not entirely sure, but I probably had to use
pgpwde  --auth --passphrase "YourPassword"  --disk 0  --all-partitions

first to get to work. Just give it a spin.


What should I do during the Man in the middle attack?

This answer is inspired by my conversation with MechMK1 in the comments.  The problem that MechMK1 points out in the comments basically boils down to authenticity, which is often seen as the achilles heel of public key cryptography.  How can you be sure the public key purporting to belong to the person that you are attempting to connect with really belongs to that person, and not an MITM?

One way to verify the authenticity of the other party's public key is to use use an out-of-band channel, such as SMS, fax, phone, postal mail, etc.

But, as MechMK1 points out, it's possible that the attacker may be able to intercept connections in these other bands as well.  Not many attackers have the ability to this, but it's not out of the realm of possibility for a three-letter agency or a nation state.  In this case, sneakernet (exchanging public keys in person) may be the most secure way to verify the authenticity of the other party's public key, if possible.

But, if sneakernet is not an option, due to proximity, time constraints, logistics, etc., then another option is to use a trusted third party, who's public key we know, to verify the authenticity of the other party's public key.  This is what SSL/TLS does, using certificate authorities (CA's).  PGP does this using a web-of-trust model.

But we know that neither of these are perfect solutions.  Perhaps the most notorious example of this was the incident involving the CA DigiNotar in 2013.

Moreover, if the CA or trusted third party is not able to verify the authenticity of the other party's public key in person, then the CA or trusted third party must connect to the other party through some network.  If the attacker has as much reach as we are assuming for the sake of this question, then the attacker can simply MITM that connection as well.

To summarize, there is no perfect solution to this problem.


Is the story about getting a visit by police for googling pressure cookers true?

The article itself clarifies that the source of the tip was an employer:

  Update: Police in Suffolk County, NY, released the following statement
  on Thursday evening:

  "Suffolk County Criminal Intelligence Detectives received a tip from a
  Bay Shore based computer company regarding suspicious computer
  searches conducted by a recently released employee. The former
  employee's computer searches took place on this employee's workplace
  computer."

Employers have a legal right to review employees' computers and Internet traffic, and if the employee was being released for any reason, it is highly likely that the employer would exercise that right - it's kind of standard to monitor people who are being released, usually to ensure they aren't exfiltrating company data.

(The article is dated August 2013; while the author doesn't time the exact incident, it's reasonable to believe the web searches would have been inspired by the April 2013 Boston Marathon bombing, which used a pressure cooker bomb carried in a backpack.  And it's also reasonable to believe that police would have paid attention to such a report in that timeframe.)


Tools to check the firewall Configurations as per PCI standards

Firewall auditing requires knowledge and interpretation, so there are no tools that will go 'ding!' and tell you you're compliant.  However, various tools can be used to make the review and audit process easier.  Two that I've used are:

Tufin SecureTrack
Nipper Studio

And many tools will do, e.g. see Firewall rule base documentation and migration tools.


You're telling John to decrypt a raw SHA256 hash, but you're creating hashes of an AES-256 encrypted string, not of the password itself.  Because the AES-256 encrypted string is effectively a very random blob, John is unlikely to ever guess it.

Try, instead, simply hashing the password and then running John against it:

root@kali:~# echo -n password | sha256sum | awk '{print $1}' > hashes.txt
root@kali:~# john --format=raw-SHA256 hashes.txt
Using default input encoding: UTF-8
Loaded 1 password hash (Raw-SHA256 [SHA256 256/256 AVX2 8x])
Warning: poor OpenMP scalability for this hash type, consider --fork=4
Will run 4 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
password         (?)
1g 0:00:00:00 DONE 2/3 (2020-04-19 14:17) 10.00g/s 655360p/s 655360c/s 655360C/s 123456..gbby
Use the "--show --format=Raw-SHA256" options to display all of the cracked passwords reliably
Session completed
root@kali:~# john --show --format=raw-SHA256 hashes.txt
?:password

1 password hash cracked, 0 left
root@kali:~#


Websites that fill back button history with questionable pages

They do not "disable" back button functionality, there is HTML5 API to manipulate the browser history. The specified site uses this functionality as could be seen in https://your-luckychance.com/media/gambling/backbutton_gmb.js

Security-wise, there are certain limitations to this API, notably you can only add entries redirecting to the same origin.

As far as I know, there is no way to recognize this happening in the browser.


I stored a copy of my KeePass database on a portable hard drive and I lost the drive. Should I worry about that?

TL;DR: You can relax - your database is absolutely secure.

Technical details:
The encryption used by KeePass is not broken as of today. Brute-Forcing the AES-256 key is infeasible. Assuming your password has more than about 80 bits of entropy the millions of key derivation rounds render brute-forcing the password infeasible, too.

The entropy of your password depends on how well you chose your words. Lets do another example:
You chose 5 distinct words. The attacker must assume a set of about 7000 english words to not miss one of your words.
The words alone make up for 10^19 possible combinations. Lets further assume you changed two letters per word to a number or a special character. You chose numbers similar to the letter and random special characters from a set of 10. The letter exchange alone makes up for (13 * 13)^5 =  137 * 10^9 possible combinations.
All in all, that is about 1,3 * 10^30 possible combinations; equivalent to about 100 bits of entropy.

Brute-Forcing 100 bits is not completely impossible imo (128 is considered impossible pre-quantum; but 100 to 128 is a huge step). That effort is far beyond feasible for anyone else than large governments or enterprises. Unless you are Edward Snowden (which i am sure you are not since you asked this question), no one will go through that pain.
The large number of derivation rounds add to that, even.


How many actions do you need to take to disable DEP

In recent versions of Windows 10, there's an "Exploit Protection" feature that allows controlling DEP on both a per-app and system-wide basis (the former overriding the latter). Use the Start search to find it.

Make sure the access violation you're getting is actually due to DEP, and not due to trying to read (or write) memory that is not mapped to the process (or is mapped unwritable, or is a guard page, etc.) If you're using windbg, the !analyze command (after you hit the AV) will give you the details.

It is never going to be the case that all addresses of a 64-bit program are executable. Even leaving aside the high addresses that are mapped to the kernel and the first page being never usable to limit the damage of null pointer dereferences, there simply isn't anywhere near enough memory - physical or backed by the pagefile - to cover so many addresses. However, it should be possible to make all mapped pages executable.

If you can't figure out any other way, you can have your vulnerable program call VirtualProtect to make the relevant address range executable before the exploit occurs. This isn't realistic for most apps (the notable exception being anything that JIT compiles its own code, if you can put your payload in there) but then, neither is a modern system or even process without DEP.


Secure communication between peers with ANON ciphers and password authentication

A large portion of the value of SSL/TLS is the validation of the authenticity of the application you are communicating with.  Yes, a MITM attack is possible in the scenario you describe.  See this other SE answer for more information.


What CVE identifier will follow after CVE-2012-9999?

The Common Vulnerability and Exposures system is maintained by Mitre.  The Mitre corporation manages the CVE list and serves as an organizer for the CVE community.

At the start of the year Mitre will allocate blocks of CVE numbers to various CVE Numbering authorities out of the full 9998 available (0001-9999).    As a result,  all CVE numbers issued to an authority within a given year will fall within a range.  For example in 2012 all CVE numbers issued to Apple products fall within the CVE-2012-3600 range.  Mitre will leave unallocated space in order to issue new CVE numbers if a CVE authority were to exhaust their supply.

So what about your question?  What if they have 10,000 CVE numbers issued in one year?   Well the most ever issued was 6,608 in 2006.  So that was close,  but since 2006 there has been an unsettling rate of decline so it doesn't look like we will ever issue 10,000 CVE numbers in one year.  If we were,  I suspect that we will have CVE-2012-10000.  They would do this because its regular,  the only reason why they have the four digit number scheme is to allow for pre-allocation to CVE authorities.

From my experience emailing Mitre is usually the best way to obtain CVE numbers.   They treat you with respect and have the option to preserve your anonymity.  Mitre will work with vendors to make sure the issues are fixed and issue a CVE to the public when a fix is available.


Alternative approaches to letting users identify themselves while maintaining privacy

My preferred solution would be for our customers to sign in upon visiting with the Username/Password they have via SSO, while all other users would be tracked in another way. Even better would be a provided membership card or something that they can simply scan to identify themselves.
(...) I can't do any of that (...)

There are three factors you can use for authentication:

First factor: Something the user knows (password): you say you can't do this one. I will assume that this is not a technical limitation. I imagine you have the technology to have a secondary database to store credentials. And you can't do that because reasons beyond the scope of the question.

Second factor: Something the user has: you say the membership card is not viable, also because reasons. There are alternatives. You could use something the user has access to. Will come back to that.

Third factor: Something the user is: for example biometrics.

I'm worried that it might be a breach of Personally Identifiable Information if I let people search by email address, and they input addresses that are not their own and can see names of people that are not them.

Yes.
The user should not see the search results unless authentication can be done. You need a layer between the user and the search.

I don't know what the odds are for that given the extremely niche use case, but it could happen.

I remind you that humans behavior is irrational, not random.
My guess is that chances of people noticing that there is no real authentication are high (they did not have to use a password or show any credential).
Beyond people using this to get information about others, I would be worried about impersonation/identity theft.
If you cannot add a software layer between the people and the search, one way to deter people from searching who they are not is the third factor: something people is. For example, a deterrent would be having a photo of the person shows up in the system and have a staff member overlooking who can compare the photo to the actual person.
That is also a way to use the third factor without putting a camera to people's face and using fancy AI software. Which are hard (for the traditional face recognition) or virtually impossible to understand (if they use artificial neural network reinforcement learning, for example), could be cheated (these systems have false positives), could be percieved a privacy invasion (where does the data go? is it being stored? is it shared with third parties?).

About the second factor...
A cheap alternative to a membership card, is to use email.
I suggest this approach (tweak it as you see fit):

The system asks the user for his email.
The user types their email.
The system searches the database for the email.
The system sends an email message with a (random, unique, single use, time limited) code.
The system asks the user for the code.
The user gets the code from the email account, and types it in the system.
If the code matches... If the email was found in step 3, the system grants access. The email exists in the system and the person proved they have access to the email. Otherwise, you can tell the person that the email is not in the database, and indicate what are the next step (is there some registration process?).

If the email can't be sent. The email the user did enter is not valid. Tell the user.
If the system is asking for the code, let the user: 1) request the code to be sent again (with some delay, let us not let people use this to spam others. You may add a captcha, not for checking if the user is human, but to slow them down and make it tedious to use this to spam). 2) abort the process and start over.
Keep in mind that with this approach the person never has to see the search results. The only way to get access as another person is to have access to the email of that other person. Either that person has the email compromised, or they granted this access.
Note: I'm not suggesting to tell people right away if the email was not found, because that could allow the user to figure out who is in the system by typing the emails of people they know. Also know that this could become an inconvenience for users (a single typo would be annoying). If you add text telling people to double check, people learn to ignore it.

By the way, if you can build the above system on top of what you have. I believe there should not be a technical limitation to implementing passwords. I will not cover how to store passwords here. Hint: you don't. You can research that if you are interested.


I uninstalled GnuPG. Can I delete the ~/.gpg folder?

Be sure you don't have keys stored in the .gpg folder that aren't saved elsewhere, and you will be fine deleting the folder.


How to Manage Public Key with Asymmetric Cryptography

The recommendation is based on the fact that it's harder to stealthy compromise a public mediation service than a single service. If they compromise keybase, with a lot of users, someone will very soon detect something wrong and warn the administrators.

On the other hand, if someone hacks your service and changes public keys, it can take a while until someone sees it. It's easier to compromise data when there are few clients, and your service will surely have way less clients than keybase.


Is there a way to uniquely identify a mobile device through packet sniffing?

Mobile devices work across many channels, often in completely different frequency bands depending on the provider.  So, even if you did have a device that could listen to traffic and watch for the IMSI/TMSI (IMSI is rarely ever broadcast, you can watch for TMSI which is a quasi-unique ID) it would need to operate across all the hundreds of viable channels, or else you are going to have to spend hours just doing one sweep (assuming your device is limited to one channel), in which time many devices will have probably arrived/left.  The practical (note this does not mean legal) way is to impersonate a base station and wait for the devices to come to you.  That is what IMSI catchers do, basically a MITM attack to get all nearby devices to admit who they are, because they think that your device is a nearby cell tower.

Here is a similar question on SE: https://networkengineering.stackexchange.com/questions/18070/detecting-2g-3g-4g-devices and here is an article about the lengths one needs to go to in order to just intercept ONE devices' IMSI without impersonating a base station: http://www.rtl-sdr.com/rtl-sdr-cell-phone-imsi-tmsi-key-sniffer/


There are mostly two kinds of attackers: the automatic, and the targeted.

Automatic attackers are not humans; they are infected machines, part of various botnets, which try to expand their basis by finding other machines to infect. Their strategy is mostly random: they try random IP address for an open SSH server, then try common passwords for common account names. There is little you can do to increase (or, for that matter, decrease) the amount of connections of this kind you will receive per day. Some network providers try to detect these occurrences and block them or limit their rate, so you could speak with your provider and see if he has such systems in place.

Targeted attackers are humans who want to crack your machine, specifically. To get that kind of attacker, you need to provide some sort of motivation. You could try to boast about some desirable "goods" stored on your server (e.g. tons of pirated copies of gams or music or movies), making it worthwhile to hijack your machine. You could try to host a political-oriented blog with highly controversial positions. Sometimes boasting will by itself attract attackers: everybody loves to shut up an insufferable know-it-all, and hacking his server looks like an efficient way to achieve it. In short words: make some enemies.

Note, though, that brute-forcing passwords is the lowest grade of attacks. If some of your newly acquired enemies are a bit competent, they will try other kinds of attacks, such as exploiting vulnerabilities in your software. Also, some of them could think "out of the box" and not target your server, but you, directly; for instance, if they look up the name of a domain you own, they might obtain your address or phone number, and pay you a visit in person. As a general rule, I advise against making enemies. There is no such thing as "consequence free"; there is only "improbable consequences".

If that is for research, then you could try to approach the sysadmins of some major sites or infrastructures. This is your senior project: therefore, there is potential academic support. With the help of your professor or advisor, you could try to see if an ISP or a big hosting service would agree with collecting data on their system; they might even find some fiscal benefit in collaborating with a scientific project. Alternatively, most sysadmins are addicted to Guinness, and may agree to help a co-drinker, especially after the third pint (your profile state that you are 17 and live in the US, so this solution cannot officially be workable for you).


Before RFTap was made available recently, you would have to configure a named pipe from GNURadio pcap output.

Which protocol(s) are of interest to you for this purpose?


Use mining to prevent DDOS attacks on websocket: Is this a viable solution?

TL;DR: This is not a solution against typical DDOS. It might be a protection against some very application specific DOS.

Taking away all the mining stuff your idea essentially means that the client connects to a server to get some hard to solve task and later comes back to present the easy to verify solution for this task.

The problem with this approach is that the clients needs to connect to the server first and that the server needs to be able to reply with a task to the client. This means your idea cannot protect against the most common bandwidth oriented DDOS attacks which simply send more traffic then upstream systems or the server can deal with. Neither will it help against simple DDOS attacks which try to exhaust resources of the server itself, i.e. things like SYN flooding or Slowloris.

It can actually help against attacks which are targeted at later stages of the processing, i.e. attacks specific to the application.  But it isn't actually a new idea in this area, it is essentially just another Proof of Work System as they are known for many years.


Difference between audit log failure/success?

A success audit entry is created in the event logs when a user logs on onto the computer/network with correct credentials, often, a username and password, and passes authentication.

A failure audit entry is created in the event logs when a user fails to pass authentication, with or without the credentials.

That said, a number of failure audits in succession of each other, against the same username, may also indicate someone is trying to brute force the password of the account.


What's the difference between "directory services" and "identity repositories"?

The really simple version:

Directory services are the means to access structured data (including protocols) + a structured data repository.

The repository may contain all sorts of information, not necessarily just identity records. It may store quite a few things - think of it as a standard/means to publish and maintain a phonebook, yellow pages, and even an encyclopedia if you like. It has indexing, search, add/remove capabilities, etc.

The identity repository is a sub-set of a directory service, typically containing only identity-related information. So it's a limited subset of the directory service. May or may not include search, indexing, or other advanced directory capabilities, however it does typically require specific access mechanisms required for authentication and authorization.


An API Key is a unique identifier that the API provider will have linked to you. It is imperative for you to make sure that your API keys are not exposed to the rest of the world. What could go wrong? Well, that depends on what the APIs can do and what your keys have permissions to do.

What could happen if someone steal the payment processor API keys? I mean, I know for example that if someone steals your Google API keys he can use Google API charging it to my credit card (there are multiple cases all around the world), but in this case the API keys are used to process the payment, I don't understand what they can do with my API keys

When someone gets hold of your API keys, they can do whatever you can do with the APIs on your behalf. So for example, if they get hold of some credit cards, they can charge use the payment processor's APIs to make new credit card charges using your identity and defraud the card owners.

Where should I store my keys

You should store your keys at any place that can't be accessed by general users and is harder to access for anyone accessing your code. Often people use services like keyvaults (provided by all major cloud providers and some independent vendors like HashiCorp). Take a look at this blog post for PHP based examples.

When developing my own API should I use authentication no matter what I am going to do?, I mean, I know that authentication is for user login functionalities, but, should I use Auth to bring products from a database?

It is not mandatory for each API to have an authentication requirement. For example the service health endpoints are usually unauthenticated. It is your decision on which API requests should come only from authenticated/authorized users. If you think that anybody(regardless whether they are a user or not) should be able to view products from a database, then its okay to not authenticate the endpoint.
When you make an endpoint public, you should ensure that you don't end up adding some code path that allows users to view something without authenticating. For example, if you have scenarios where everyone can see the basic products but you need to have an account to view say the VIP products, then its your responsibility to ensure that your public endpoint doesn't have any way to show the VIP products.

When generating API keys for others to use my service, is it safe to store them in a database?

Whether it is safe to store them in a DB or not depends on your threat model. There is a risk of someone gaining access to your DB and as a result, getting access to the keys. If you encrypt the keys before storing them, then you reduce the risk a bit. There is actually an answer about this on stack overflow: https://stackoverflow.com/questions/37951220/storing-api-keys-on-server/37953361


Why is location very highly secured info on smartphones?

Well, many people consider Location data to be sensitive, as you'd imagine. The classic example is someone being stalked - they don't want their location out on the Internet anywhere.

I suppose what's special about location is that it usually happens automatically and so it's easy to accidentally leak information.

For example, I'm unlikely to accidentally put my home address on my Facebook wall by typing it in and pressing "post".

But suppose I use my phone to take a photo of my dog looking cute in the back yard and tweet it. If my twitter client geo-tags the picture automatically and silently, then my address is going to leak without me realising.

One other factor: there have been a couple of recent security breaches in relation to location on phones, particularly "Locationgate" on IOS and the whole CarrierIQ thing. You could argue that both were blown out of proportion by the media but they certainly got a lot of attention - questions in Congress, even - so vendors are taking particular care when location is involved.


The only way to easily accomplish this is to not allow the user to decrypt the file themselves.  If you build a system that will handle the decryption and never give the user the actual decryption key, then you can give each user a key that the application uses to decrypt the key used to protect the shared data.

To remove a user, you simply delete the copy of the shared key that is encrypted with their user key.  The entire security of such a system depends on their inability to ever actually get at the key used to encrypt the shared data.  If they get that key, then it is impossible to prevent them from opening the encrypted file anytime they choose.


Why no different languages in passwords?

In general, there is no reason not to use arbitrary characters in a password, unless the system processing the password does something stupid with them (like removes them completely, leaving an empty password).

In the bad old days of language-specific character sets, there was always the risk that a password with non-ASCII characters might stop working when you switched to a different computer, because it was encoding those characters differently.  But nowadays everybody's pretty much standardized on Unicode as the standard universal character set, so that reason rarely applies unless dealing with old legacy systems.

(Of course, we still have different ways of encoding Unicode characters into bytes, like UTF-8, UTF-16-LE/BE, UCS-32, etc., but at least those are generally pretty well under the receiving program's control, as opposed to depending on the user's OS and/or terminal settings like charset selection used to be.  And, honestly, UTF-8 is becoming pretty well established as the standard Unicode encoding for I/O purposes, even if some software may use other encodings internally.)

In fact, using characters from a wider pool makes it harder for an attacker to guess your password by brute force.  That said, making the password slightly longer generally does that more effectively than sprinkling "weird" characters into your password (obligatory xkcd link), so you should only use non-English characters in your password if you can type and remember them easily, e.g. because you speak a language that uses those characters.

Still, there are some reasons why you might sometimes not want to use non-ASCII characters in your password:

They might not be easy to type, if you ever need to log in from a shared / borrowed computer with a different keyboard, or if your own computer's keyboard layout gets switched for some reason.

(Actually, the same goes for ASCII punctuation too, since a lot of keyboard layouts like to switch those keys around.  But at least you usually can type them on any keyboard.)
The system processing the password might not accept them.  People have funny ideas about what counts as a valid password, and especially some older systems (and especially if they were developed in the US) might simply refuse to accept anything but printable US-ASCII characters in passwords.  They might even have sort-of-valid reasons for doing that, e.g. if the passwords are internally passed between old legacy systems that use different character encodings, or that break on non-ASCII data in some way (see below).
Even on the client side, some of those old charset issues might still rear their head.  For example, if the password is typed into an HTML form on a web page, and if the page does not explicitly specify its character encoding, different browsers might auto-detect different encodings, causing the password (and any other text entered into the form) to be encoded differently.
For some writing systems, Unicode normalization could also cause problems.  Without going into details, there are several equivalent ways to represent many characters in Unicode.  If the password processing system does not explicitly run the password through a Unicode normalization algorithm before hashing it (and many do not), then it's possible that typing the same character on different computers might result in a different sequence of Unicode code points, causing passwords using that character not to match.

If the back-end that handles the passwords was never designed or tested with anything but ASCII characters, it might also simply break when given input it doesn't expect.  For example:

Different parts might handle non-ASCII characters differently.  You might expect that all password processing in a given system would go through the same code, but in practice, there could well be multiple implementations password hashing (e.g. for different user interfaces to the same back end data), and they might not agree 100% on unexpected inputs.  This could e.g. mean that your password might work over the web, but not with a native client app, or vice versa.
The system might strip away non-ASCII characters, or even truncate the password at the first such character.  You'd think that would be a crazy thing to do for a password (and it is!), but the system might e.g. be running all input through some generic "input sanitization" function that simply strips away anything it doesn't recognize as "safe".  In most cases, that's not a terrible security measure to take (even if it would generally be safer to signal an error instead of silently discarding data); for passwords, it could be disastrous.
The system might internally use non-ASCII characters as delimiters, on the assumption that those characters will never appear in real data.  That might seem like a silly thing to do, but I've seen it done, including here on Stack Exchange.  At best, such as design would force the system not to accept such characters in the delimited data; at worst, using such characters could cause the data to be truncated or garbled.  Obviously, that could be really bad for a password.

(Of course, some systems may do this with ASCII delimiters, too, leading to silly restrictions like "password may not contain @ or %".)
The system might limit the password length.  A lot of old password hashing schemes (and even some relatively modern and otherwise seemingly decent ones, like bcrypt from 1999) will not accept passwords longer than some number of bytes, and may even silently truncate passwords longer than the limit.  This is a potential security problem in general, but it can be exacerbated by the use of a variable-length encoding like UTF-8, where non-ASCII characters take up two or more bytes per character.  Thus, for example, a system that limited passwords to 16 bytes of UTF-8 could handle a 16-character ASCII password, but only 8 characters of e.g. Greek or Cyrillic text.

The upshot of all this is that, in general, using only printable US-ASCII characters in a password is least likely to trigger software bugs or limitations.  Given that password handling bugs can often be difficult to deal with (since the only response you'll often get is "invalid password"), a lot of people may find it easiest and safest to stick to them.

If you do want to use a non-ASCII password (e.g. to make yourself less of an easy target for brute force password cracking, or just because it's easier for you to type and remember), you may want to test that the system really handles your password in a (reasonably) sane way.  I would suggest testing at least:

that you can log in with your password (using all available login methods, if the system offers several, and with all browsers or other clients you're likely to use);
that all features linked to your password (like, say, encrypted storage) really work correctly; and
that you cannot log in with simple variants of your password, e.g. with some non-ASCII characters changed or with extra characters appended to the end.

In any case, there's an argument to be made that, at least in 95% of all cases, you should not be choosing your own passwords anyway.  Rather, you should be using a secure password manager, and letting it generate random passwords for you.  Such randomly generated passwords will typically be long strings of random printable ASCII characters, to maximize entropy while minimizing potential compatibility issues, but it really doesn't matter much since you don't need to type or memorize them yourself.

Of course, you do still need to choose a password for your password manager.  But hopefully your password manager, at least, is well written and will handle non-ASCII passwords correctly.


Did CVE-2016-2324 allowed remote code execution?

A buffer overflow (of the "write" kind) gives any advantage to an attacker only if the attacker can arrange for the overflow to spill over other bytes that are used for something else. At any time, the process runs in an address space, most of which being unallocated. If the buffer which is overflown is at the end of the address space, or is followed only by unused bytes then an unmapped page, then the overflow won't help the attacker.

I remember a case with the rlogin command-line tool on SunOS 4.1.4 (sparc systems). It was root suid, and you could get it to segfault if the TERM environment variable contained a string longer than 64 characters. However, the overflown buffer was at the very end of the data section, and there was nothing beyond that to overwrite.

Mind, though, that malloc() may use extra bytes before and after each allocated block to keep track of which blocks are allocated. Depending on the implementation of malloc(), modifying these bytes may or may not help the attacker. The bottom-line is that while some buffer overflows cannot be exploited, it is usually very hard to make sure that a buffer overflow cannot be exploited. It is safer to assume that any buffer overflow can lead to drastic consequences, and not allow them to happen at all.


Working from many places  being able to restrict SSH access to server to IP range

Setup ssh key authentication and disable password authentication (ensure you don't lock out yourself!)

In order to log in, an attacker would need to prove they own the same ssh key as you, which -barring bugs such as the debian fail- would be infeasible.


CVSS is a scoring system, it is subjective and is open to interpretation by the person scoring the vulnerability, if you look at the two scores you'll see that one rates high confidentiality impact and one rates none.

On which one to use, there is no real right answer here, it's what's right for you. In my organisation we use  version 3, this guide from Acunetix might help you make up your mind.
Acunetix CVSS version guide