How do I encrypt the source and destination IP address, along with various parts of an email?

To protect packet destinations, you need to abstract the network layer entirely - which usually means some form of encrypted VPN. This would mean no hardware on the local network would know what packets are being transmitted, where to or what they contain.

Unfortunately, this doesn't solve the real problem, just moves it upstream. Your VPN/encrypted link has to connect to the real network at some point and as soon as it does, you'll be forced to use correct routing information. You could mitigate this by moving IP blocks every so often / having multiple connections to the 'net but this could be complex to maintain.

An improved approach might be to use TOR to mask routing from your network. It's not perfect but it's another layer of defense.

So perhaps an SSL SMTP connection over your encrypted vpn to your mail server and encrypted email over TOR to the recipient(s) mail servers. (SSL on top of your VPN encryption to protect against other machines on the VPN. You may want to consider client certificates to guarantee the source of the email)

Edit: Having just spotted your use case in comments, and focusing purely on protecting the connection to the smtp server, I think it'll depend on how easy it is to uniquely configure the sensors.

If it's cheap, use a unique SSL client cert with each sensor. This will both secure the connection and confirm the ID of both parties - no spoofed sensors.

If it's costly to configure, use something PSK based - You still get the encryption but if one device is compromised, they all are [at least to anyone inside the VPN].


Resources to learn about Windows systems exploitation

windows is a close source OS so, your work is hard.

  you need learn basically about windows Architecture and you need learn
  Assembly with c/c++ language for attack.

specially Assembly.
also about this sentence :

  i used book about nmap, Metasploit, exploit writing etc..., but they
  contained too much information about too many OS's

this tools for penetration testing only is used.not for learn exploitation at kernel or system.
as you said at title :

  about Windows systems exploitation

if you need learn about Exploits and vulnerability's, see Submited Exploit's at something like that :
Exploit-db

for example : Windows 8.1

i hope my post is usefull for you, but with search about Architecture about your mind OS, you can learn every thing  :)
goodluck.


I've heard that salt is not meant to be secret, but what if I made it secret?

Lets assume a hacker got ahold of your database.

Lets analyse what happens when you store the encrypted salt into your database.  The hashing function that utilizes the encrypted salt won't be able to use the salt until it is decrypted.  So your code would request the encrypted salt and would need to be decrypted with a key.  We can assume this key is in the code.

Since the hacker has your database, they will have the encrypted salt.  Now they really only need the key.  In your example, the key is stored in the code.  Normal salts are going to be stored in the code as well.  You really don't add any security at all here since the hacker can simply decrypt salt by getting the key from the code just as if they were have to got the salt from the code.

Most hashing function are going to have enough entropy that you can't analyze the string to figure out which hash function was used.  However you can visually see that different hashes contain a different amount and type of characters, which will give you a better clue on which is being used.

If a hacker were to get your database, getting your code may be just as easy.  The purpose of a salt is so it can't be subject to a rainbow table attack.  But of course they would be able to generate a rainbow table but it may take too much time to do so.


When using metasploit with my python reverse shell script I get a byte error, but it seems to work fine when using a netcat listener

I believe the payload you are setting up in the metasploit handler is a staged payload (more info: https://metasploit.help.rapid7.com/docs/working-with-payloads). This means that the Python script is receiving the final stage but does not know how to handle it and, thus, crashing.

Try doing the same thing, but using a stageless payload such as windows/x64/shell_reverse_tcp instead and see if it works.


SSH session_id in RFC 4253 (key exchange)

It is in the source code of openssh as described in the RFC and we can simply trace its source from there:

/* K1 = HASH(K || H || "A" || session_id) */
if ((hashctx = ssh_digest_start(kex->hash_alg)) == NULL ||
    ssh_digest_update_buffer(hashctx, shared_secret) != 0 ||
    ssh_digest_update(hashctx, hash, hashlen) != 0 ||
    ssh_digest_update(hashctx, &c, 1) != 0 ||
    ssh_digest_update(hashctx, kex->session_id,
    kex->session_id_len) != 0 ||
    ssh_digest_final(hashctx, digest, mdsz) != 0) {
    [...]

From the RFC:

  The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection.

This means, that the session_id is equal to hash (H) for the first key exchange. If there is another key exchange later, it is always the hash from the first key exchange.

Checking also code of DH:

/* calc and verify H */
hashlen = sizeof(hash);
if ((r = kex_dh_hash(
[...]

if (kex->session_id == NULL) {
    [...]
    memcpy(kex->session_id, hash, kex->session_id_len);
}

if ((r = kex_derive_keys_bn(ssh, hash, hashlen, shared_secret)) == 0)
    [...]

confirms this idea. First we calculate H, then we update session_id (if not set already) and then we derive the keys (code above).


Risk of routing malicious email through internal email infrastructure

This depends if the mail is only routed (i.e. simple MTA) or if any kind of deeper analysis will be done (firewalls, IPS, BDS...). In the first case there is probably not much of an risk. But in the last case it is possible that the malware will be extracted and analyzed by some middleware. Such analysis is a complex issue and often contain bugs. In the worst case the analysis system itself could be compromised this way.

This is not a hypothetical attack. Such attacks happened against FireEye BDS where the passive monitoring of the traffic done by the BDS could be turned into an exploit. And another such issue existed with Symantec Endpoint Protection including Symantec Email Security. And probably others are affected too.


Is storing answers to security questions in plain text bad form?

I'll assume the model you're trying to defend against is where an attacker has access to the database. If that's the case, yes, it's a bad idea if an attacker can compromise an account by only knowing those details.

My advice would be to convert the answer to uppercase, then salt + hash it. Optionally also trim it or collapse all whitespace. This provides a reasonable security measure without reducing usability.


Is TCP Sequence Bruteforcing dangerous nowadays?

What is the future of TCP sequence Bruteforcing?

I'll argue that it is not as dark as it may seem at first.  Guessing a 32bit number is not feasible, even if you send a lot of packets with attempts.  As @armani said, using a DDoS size bandwidth is most likely to make the machine not respond rather than accept the spoofed packet.

Yet, there are other ways.  All of them are based on the fact that you can reduce the search space (32bit) to a more amenable amount.

Years ago Michal Zalewski performed a research where he made time series of the pseudo random number generators.  The time series allowed to guess the next number based on a couple of previous ones.  Knowing some packets allowed to make a much better guess against systems where the PRNG was somehow predictable.  And guess what, most systems have a rather predictable PRNG.
A year later Zalewski checked if the PRNGs did improve after he reported the issues.  And the improvement was not so great.
Even attempts to to protect from ISN guessing backfired in the past.  CVE 2016-5696 happened because an RFC (RFC 5961) did not define things properly and implementations (actually the one single implementation in the Linux TCP stack) became more vulnerable.  They became vulnerable because they provided sequence numbers through ACK challenge packets that could be used in determining the PRNG sequence (in techniques similar as point 1.).  Once the number of allowed ACK challenge packets was reached, you not only could try guessing as normal, but had several packets to base your PRNG analysis.

We (OS developers and security analysts) keep making mistakes with ISN.  And, although popular and updated systems are unlikely to be vulnerable (Linux is fixed those CVEs), not all systems are updated.  Moreover, as seen in Zalewski's research, router OSes do not fare much better on PRNG predictability.  And router OSes are often left not updated.

There is still future for sequence guessing, not necessarily plain brute-forcing.  But the guessing, still involves some brute-forcing.  You can guess a couple of ranges a PRNG can come up with, and from there you need to send several packets with different sequence numbers each based on the ranges (using all numbers in the guessed range in the best case).

It is becoming harder and harder to make viable spoofing attacks on TCP sequence numbers.  But is isn't impossible.

References

Strange Attractors and TCP/IP Sequence Number Analysis - Zalewski
Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later
TCP “off-path” Attack (CVE-2016-5696)
RFC 5961


How to whitelist an Amazon ELB in a(ny) firewall?

If the customer is as security aware as the question imply's then they will understand that the only reliable way to perform the task would be to whitelist traffic to the IP address range for Amazon ELB service.

If the worry is that this would allow other websites using the same service external access then a proxy server or secondary firewall would be required to ensure that the traffic to these IP's was only for the website(s) allowed.

It is a little hard to be more specific without a greater knowledge of your customers layout.

However in one of the services I support it would be done by using a Bluecoat proxy to control access to the external website.

It would also be preferable to also only allow authorised clients using AD controls,  the traffic is then sent to the firewall via a VIP address on the Bluecoats external interface that is only for traffic for this service.

The firewall can then limit the access to the IP destination range from the source VIP only.

Any proxy server should be able to do this and if your customer isn't using one then a second firewall could be used with SNAT to do the same thing.  First firewall allows access to the website then forwards the traffic to the second firewall on a SNAT, SNAT is used as the source address for a source/destination match to the external IP address range.

This would avoid the issue of DNS poisoning as any response would still have to match the allowed IP address range on the firewall.


Secure connection between two clients with shared secret

There are three cases you may want to consider:

You want to use TCP as the underlying transport protocol and can afford public-key cryptography.
You want to use TCP as the underlying transport protocol but can't afford public-key cryptography (because it would be too slow, applies mainly to IoT devices)
You want to use TCP, but you want security at a lower level.

Now the first two scenarios have the same answer: You want to use Transport Layer Security (TLS) v1.2 or newer (as soon as v1.3 gets standardized).
TLS offers multiple ciphersuites, which define which methods to use for key-exchange, for authentication, for buld-encryption and for shared-secret-derivation.
The general setting you want to use is TLS-PSK in the first two scenarios.
The ciphersuite of choice is TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256 as long as there is no TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 (which may be standardized soon). This will only use pre-shared keys for authentication and ECDH for key-agreement, giving you different keys for each connection (which is good).
In the second scenario the ciphersuite of choice is TLS_PSK_WITH_AES_128_GCM_SHA256, giving you a modern ciphersuite. The drawback is that the keys aren't negotiated separately, meaning if you once lose the master-secret all connections (future and past) will be compromised, which wouldn't be the case with scenario 1.

The last scenario is a bit more complicated and I'd strongly suggest you to stick with TLS. However if can't use TLS (which is widely available), you have to use IPsec, which offers PSK authentication as well. This will secure the connection at the IP level.


What is this weird localhost IP traffic on multiple ports in the 5400-5600 range?

I got the time to track it down, and it looks like I found the answer. It's 'adb', the Android Debug Bridge service, installed with the Google Android tools package. I had put it on my machine to help unbrick my daughter's phone (don't ask) and forgot to shut it off. But that was months ago, and like I said I didn't see the traffic in my desktop widget (Gnome/MATE System Monitor applet) until after I updated the OS on Apr. 19th, and not immediately after the update. I am digging through the release notes on the list of updated packages now to see if there was a networking-or-other package that updated something to bring this up on the radar.

Anyhow I'm recording the steps I took here in case someone wants to know how I found it, maybe it'll help someone someday. I started by using Wireshark, but not really knowing what to look for all I could note was that the pattern started at port 5401, ran every odd numbered port up to 5699, and then recycled. Then I went back to the basics and looked up the man page for lsof. I ended up using the lsof command like so:

lsof -i :5000-5700

It shows all processes using internet ports 5000 through 5700. A couple processes showed up, 'adb' being one of them (listening on port 5037) . 'avahi-deamon' showed up too, running UDP on mDNS (port 5353). I don't run Zeroconf/Bonjour/whateverthenameisnow, so I shut down avahi-daemon. No dice, still had the traffic. Then I went to look up adb, it had no man page, no apropos, no whatis, and a 'dnf whatprovides /bin/adb' came up empty. Strange. However running a 'strings' on it and piping it to less showed the word ANDROID show up a few times. Bingo. I took a look at the services list in systemctl, and saw 'adb.service' was enabled. I shut it off with 'systemctl disable adb.service', and wala, like magic the traffic stopped.

Now, doing that was just a shot in the dark, I did not know for sure it was adb that was making the traffic before I shut it down. After all I could only prove it was listening on port 5037. I wonder what it is doing looking through all those ports. Obviously trying to connect to something. When I get more time I will look through the documentation.


What lawful interception standards are used outside Europe?

CALEA in the US: http://en.wikipedia.org/wiki/CALEA


Content Security Policy against clickjacking fails with static PoC

Since you "static PoC" is just a static file loaded from disk there is obviously no HTTP server involved. This mean there is no HTTP protocol involved in serving the data and thus no HTTP header exist where the CSP header is set. This effectively means that your static PoC for CSP is no test for CSP at all since there is no CSP policy declared in your test. And without a declared CSP policy none will be applied.


Simply put: No. Hashing is a one-way function and cannot be "decrypted" or "reverse engineered" (given you are attacking any semi-current hashing algorithm). Therefor, you need to hash all the potential passwords and compare those hashes against the hash you are trying to break.

If the hashes are not salted and not peppered, it is enough to calculate the hashes of all potential passwords once and compare them to the password hashes.

If the hashes are salted and/or peppered, you need to hash all potential passwords with the given salt/pepper and compare them against the individual password hash.

All of this is under the assumption that you know what hashing algorithm you are dealing with and how it is configured (iterations, salt, pepper, etc.)


What are the dangers of not setting the HSTS header on every response?

It would be recommendable to have the HSTS header set on every HTTPS response, but this effectively provides the same level of security, because the HSTS policy is cached for the max-age seconds. It's defined that the lack of Strict-Transport-Security header doesn't cause deletion of the policy, but only settings a zero value for the max-age (RFC 6796 6.1.1, 5.3 & 12.5). Also, settings a value too low causes it to expire too soon.

These setups can protect a user that has visited the page on a trusted network (or a browser seen the HSTS header on it, to be more precise) within the max-age seconds. If the URLs providing the HSTS header are loaded on every visit, this wouldn't really compromise this. Despite that, I can't see any reason not to move this configuration on hostname level, and it might just be a mistake, too.

However, this prevents from protecting the users before they have ever visited the site (which would be the next step & level), as the presense of Strict-Transport-Security with both includeSubDomains and preload on request to / is mandatory, if you wish to add the domain to an HSTS Pre-Loaded List. This is the only way to protect the whole example.com, *.example.com, *.*.example.com etc. in advance. In addition, hstspreload.org requires that the max-age must be at least 31536000 seconds (1 year).


Security of using passwords or even passphrases to encrypt files

You are thinking of two things:

Kerckhoff's principle. The main idea is that the key needs to be the secret. If any part of your system requires the algorithm to remain unknown, your system is in deep trouble. The term for any system that requires the secrecy of the algorithm is "security by obscurity" and it is derided as terrible, because it is terrible. The national security agencies get away with it because they also ensured that even with classified hardware, Kerckhoff's principle still applies. This is why when John Walker started handing over code strips to the Soviets, they didn't have the hardware, so they convinced the North Koreans to seize the USS Pueblo. The NSA knew that the machinery seized would be worthless without the keying material - not knowing that the Soviets were getting a complete set of code keys for most of the US Navy.
The entropy of your password. Shannon determined that the entropy of English words ranges between 0.6 and 1.3 bits per character. This means that if you need 40 bits worth of entropy for your key, and you pick English words, you'll need pass-phrases between 31 and 67 letters long. This is behind the reason folks ask for upper & lower case letters along with digits and symbols: to increase the entropy.


Bots trying to spoof encoded email links, but why?

Since your links do not contain a target URI, there are only a few possibilities for an attack here:

The attacker has (or assumes to have) found a way to route through your redirector (unlikely)
An attempt to damage your web reputation; look up your domain for URI DNSBL listings
An attempt to water down your service in the eyes of your users
The attacker assumes your anti-spam system whitelists emails with such URIs
An attempt at Bayesian poisoning (which doesn't even work) or another nonsensical task

Perhaps there's a bug in your (and/or the attacker's) code, but I'm guessing it's more of an annoyance than anything else: damaging your reputation in some way (to your users or globally) or trying to game some anti-spam system.

If your redirector had retained the target URI

I had originally assumed that your redirection service retained the target URI, something likehttps://host/redir?hash=b17d56eb7444&uri=http%3A%2F%2Fexample.com given hash = substr(sha1("s3cret_pepper:" + uri), 0, 12) and that these forgeries failed the verification but the attacker was too stupid to have checked that.

In such a case, the redirection targets in these messages would probably be malicious sites.

This would be web reputation hijacking, in which they're using your redirector's reputation in place of the likely bad reputation of their own landing site, thus bypassing URI DNSBLs in spam detection.

Another possibility is that they don't like you and they're trying to damage your web reputation.

A third possibility is that they're trying to trick your users (and/or your internal whitelisting) into thinking these links are safe.

The first two scenarios are likely to harm your web reputation. Look yourself up at a site like http://multirbl.valli.org/lookup/ to see if you've been blacklisted already (and compare your reputation to that of the sites this attacker is trying to redirect to).


Will a virus/malware travel between devices when logged into the same Google account

If you have Google Drive set up to sync files, then the infected files might transfer over. But to get infected, those files would need to be run on the new machine.
Just having infected files does not mean that you are infected.


SambaCry CVE-2017-7494 returns "Exploit completed, but no session was created"

Target might have some sort of antivirus. Also maybe you mistyped some of data like lport,lhost.


I could not find an out-of-the-box solution for this, however I think this can be done by scripting a little. Here are my thoughts.

Set up Snort to alert on TCP handshakes to SSH target ports. Have it log these alerts to a file. Also set up traffic alerts to/from SSH ports. Write these alerts to a file as well.

Then, create a script which correlates these events and alerts if a connection is alive for too long.

A simple state machine should do the job. If the handshake alert is encounter save the from/to ip to some kind of storage (can be memory) as well as the ports and the time of the alert. Have a last seen date saved as well and update that as you see traffic between the two hosts. Check if the difference between last seen and connection established is greater than your preference.


You're doing it correct, you're just not using the correct string format.  The injected printf is reading memory 8 bytes (64 bits) at a time, but you're only printing 4 byte (32 bit) hex dumps.
Try using a "long" version of the hex format instead: %016llx:

$ ./a.out "`python -c 'print "%016llx\n" * 30'`"
Data: 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
0000000000000000
00000000ffffc8e8
000000018013ff20
4141414141414141
4141414141414141
4141414141414141
4141414141414141
4141414141414141
4141414141414141
00000000ffff0041
0000000000000000
0000000000000000
...


Is it trivial to protect from double free just by LD_PRELOADing a custom malloc/calloc and free?

No. The reason double free is a vulnerability is that the memory has been reallocated for something else before the second free. Any such wrapper would have no way of knowing whether the free was intended for the first or second allocation of memory at that address.


If bruteforcing a password goes aaa, AAA, aab, AAB, etc, all the way to ZZZ, wouldn't ZZZZZZ be the most secure password?

The attacker is in your head. By this I mean that the attacker knows you and knows your password generation strategies. If you systematically use passwords beginning with a 'Z', then he will start his search with such passwords. (Especially since you have described this very method on a publicly readable Web site.)

You might have an edge if you choose your passwords differently from everybody else; but attackers adapt, and adapt fast. Choosing 'ZZZZZZZZZZ' as password is strong only as long as attackers try potential passwords in alphabetical order; and attackers have already stopped doing that. They first try passwords with "structure", such as ten repetitions of the same letter, because that's a kind of passwords that human users choose (then they continue with derivations from common words and names).

It is hard to outsmart attackers; it is especially hard to know how much you outsmarted attackers, because smartness is not something that is readily quantified and measured. The normal stance is to assume that the attackers knows everything about your password generation process, save the random choices within that process; this is the only way you can reliably estimate the strength of your password.

Regardless of how you choose your password, an attacker who is intent on trying all possible letter combinations can always generate these combinations in a random order, which guarantees him the theoretical average success rate of N/2 (if there are N possible passwords, he will try on average half of them before hitting the right one). There is no password generation method which can be used to prevent that.


Identify Malicious/Suscipicous Processes from Process List

The list of common/legitimate processes will depend on the OS installed. Also, the list will depend on the software you have installed on your machine.

In Windows, you can trytasklistIn Linux, you can try ps

You can make a list of trusted applications(which you can do manually or lookup online). Then, after getting the list of running processes programmatically, you can compare the list with your trusted list of processes and display only the remaining processes.

If you feel that some these processes are harmless and legitimate, you can add these processes to your list of trusted applications, so that they won't show up again next time you run your program.


Does DirectAccess protect non corporate traffic on public wifi?

By default, no.   DirectAccess enables split-tunneling by default, so only requests for corporate network resources will be protected by the VPN, and all other requests will be handled by the local network, so requests for things like online banking sites will only be as secure as they would otherwise be on the network you're using, as if DirectAccess wasn't connected at all.

Additionally, I don't believe that split-tunneling is an end-user configurable option with DirectAccess.  I believe it's administrator configured.  I don't see a setting for it on my machine in any case.

You final question is likely unanswerable. Could a university network be as secure as a corporate or home network?  Sure, why not?  They use much the same technology after all, and many home wifi networks, at least, are horribly insecure.  However, that says nothing about the security of a specific network, so is effectively useless information.


Chrome flagged a website as insecure and it is asking for my credit card details

verify error:num=20:unable to get local issuer certificate

First, openssl s_client is not using the Windows certificate store but requires a certificate store in a different format and in a different location - and commonly there is nothing installed there on Windows. That's why it cannot find the root CA in the local trust store which results in the error message you see.

But, the certificate validates correctly in Edge, IE and Chrome since these all use the Windows builtin trust store. And while Firefox does not use the OS builtin trust store it ships with its own which also contains the required root CA.

The real reason the site is reported is insecure is because it forwards HTTPS traffic to plain HTTP. This means while it has a valid and properly installed SSL certificate and could in theory use HTTPS to protect the connection it explicitly abandons HTTPS and forces the browser to use plain unprotected and insecure HTTP:

$ curl -v https://service.electrostub.com
...
< HTTP/1.1 302 Found
...
< Location: http://service.electrostub.com/index.cfm?
            ^^^^^

If this is by design or because of a misconfiguration of the site I don't know, although misconfiguration is more likely. From the client side there is nothing you could do to fix this problem. Instead it needs to be fixed by the operators of the server.


Is it possible to wrap and export RSA private key in FIPS 140-2 Level 3 compliant hardware?

FIPS 140-2 does not explicitly forbid key export; what it says is that the module shall prevent unauthorized disclosure; it furthermore states that when a private key is exported from a module, it shall be done with encryption. The important word is "unauthorized": simply encrypting with an AES key is not enough; that key must also be such that it is known only to "authorized" systems or people, and this depends on a lot of other parts of FIPS 140-2. Basically, you cannot export a private key "generically" simply by virtue of having employed encryption; it must be part of some documented procedure that itself complies with the roles and constraints defined in FIPS 140-2, and has been evaluated as part of the process that allowed the module to be "certified FIPS 140-2 level 3".

To make the story short:

Some modules will never allow a private key to be exported, regardless of encryption.
Some modules will allow a private key to be exported only if, at key generation time, it was tagged as "extractable" (see the PKCS#11 "CKA_EXTRACTABLE" attribute).
Some modules will allow a private key to be exported but only as part of a fully-specified procedure that is covered by FIPS 140-2 level 3; in practice, this happens only for moving keys between two equally 140-2 compliant hardware modules.

It is very improbable that a certified FIPS 140-2 level 3 module allows unbounded private key export, only protected with an externally provided AES key, and is still FIPS 140-2 level 3.


What is next step after nmap + metasploit?

What to do after nmap and metasploit depends on where you are. I'm also around the "script kiddie" level but I'll list some tips I've seen from experience and others:

Before you connect to the box:

Do some automated scans like nmap, nikto, wpscan, sqlmap, etc
Check the software versions. They often use out-of-date and unsecured software with known vulnerabilities
Google. You should try to understand what those softwares do and how they may be exploited.

If you're on a WepApp (in a browser):

Look at robots.txt and sitemap.xml. Useful links and folders are sometimes in there.
Crawl it (with zaproxy or Burp Suite or some other crawler) and brute force some directories and files (with dirb, dirbuster, gobuster, etc.) to look for interesting folders and files.
Poke around. Just go around the app, learn about. You may find some prompts, boxes for user input, search boxes, file uploads, etc. that you can exploit.
Use Developer Tools. You can probably access it by pressing F12. Use Inspector and Inspect Element. The authors sometimes leave some helpful hints in the comments.
In Developer Tools, look around at some .js files. There may be some interesting functions.

If you're connected to the box with something like nc:

Go around and explore. Just cd into folders. If you know the Linux or Windows file system (depending on the box you're trying to hack), you can quickly spot some "out of place" folders and files.
whoami to know your privileges. history to look at, well, history. Users sometimes enter credentials in commands and they get stored in history.
Dump hashes. /etc/shadow is an example. You can try and crack those hashes or "pass the hash".
python -m SimpleHTTPServer 8080. (Use whichever port you like). This can allow you to upload files from your local machine to the box.
nc -lvnp 8080. (Again, use a port you like). This will open a nc listener. I'll leave you to explore how you can pop shells with this.

Those are just a few things you can do. One of the most important things is to "poke and explore". Look around for user input, unusual files and folders, implemented functions, etc. Also, document as much as you can. It'll be much easier to know "where that reverse shell script" was put in the box. It'll also help a lot when you do a write-up.


What parts of an SSL Certificate can I share without revealing the Certificate Authority's identity?

Based on my understanding of your question, you are trying to prove that your employer is intercepting and inspecting your HTTPS traffic.

Ok, you've found your company's CA cert in your java trust store. That tells us that they have the ability to perform the MitM attack that you are describing, but it does not prove that they are actually doing it. That cert may be there for a completely legitimate reason, like for example so your VPN client can authenticate the VPN server, or so you don't get certificate errors when connecting to internal network resources.

To be sure that they are inspecting HTTPS traffic, you need to actually catch them in the act. When you make a TLS connection that you suspect of being MitM'd, look at the server cert you are presented; if it chains to your company's CA then that connection is being MitM'd and you'll have proof, but if it chairs to a publicly trusted CA then it's secure.

You'll need to do some digging about the java application you're using to figure out how to see the details of each TLS connection (you may be able to do this through JVM settings, but I'm not sure). Browsers, for example, are quite good about showing you the details of the TLS connection.


Using the middle name instead of first name for OpenPGP?

There is no ruling what people have to sign or may not, everybody will decide on his own. You might miss some signatures, but I guess most people will not care about which of the first names is included.

Quite a lot people (at least loosely) follow the rules defined by the CAcert Practice on Names document, as CAcert had some well-grounded discussions on names. CAcert's require one, but allow any number of first names to be listed in the certificate.

You will have larger problems when using nicknames, like widely spread in the Netherlands.


What is the difference between a penetration test and a vulnerability assessment?

I'm sure I posted an answer to this previously, but my google-fu must be weak this morning. From my blog post on Penetration Taxonomy, we have a list of testing types that is gaining acceptance. Also, working with the Penetration Testing Execution Standard we hope to further develop this. This list should help explain how to choose one over another.

Deliverables are almost a separate issue - and should be defined by the need and the audience (eg for a governance body you would not expect the same detail as you would provide to a technical remediation team, but you would want to include business risk information). There is also a Reporting stream within PTES development to try and codify this area:

Discovery

The purpose of this stage is to identify systems within scope and the services in use. It is not intended to discover vulnerabilities, but version detection may highlight deprecated versions of software / firmware and thus indicate potential vulnerabilities.

Vulnerability Scan

Following the discovery stage this looks for known security issues by using automated tools to match conditions with known vulnerabilities. The reported risk level is set automatically by the tool with no manual verification or interpretation by the test vendor. This can be supplemented with credential based scanning that looks to remove some common false positives by using supplied credentials to authenticate with a service (such as local windows accounts).

Vulnerability Assessment

This uses discovery and vulnerability scanning to identify security vulnerabilities and places the findings into the context of the environment under test. An example would be removing common false positives from the report and deciding risk levels that should be applied to each report finding to improve business understanding and context.

Security Assessment

Builds upon Vulnerability Assessment by adding manual verification to confirm exposure, but does not include the exploitation of vulnerabilities to gain further access. Verification could be in the form of authorised access to a system to confirm system settings and involve examining logs, system responses, error messages, codes, etc. A Security Assessment is looking to gain a broad coverage of the systems under test but not the depth of exposure that a specific vulnerability could lead to.

Penetration Test

Penetration testing simulates an attack by a malicious party. Building on the previous stages and involves exploitation of found vulnerabilities to gain further access. Using this approach will result in an understanding of the ability of an attacker to gain access to confidential information, affect data integrity or availability of a service and the respective impact. Each test is approached using a consistent and complete methodology in a way that allows the tester to use their problem solving abilities, the output from a range of tools and their own knowledge of networking and systems to find vulnerabilities that would/ could not be identified by automated tools. This approach looks at the depth of attack as compared to the Security Assessment approach that looks at the broader coverage.

Security Audit

Driven by an Audit / Risk function to look at a specific control or compliance issue. Characterised by a narrow scope, this type of engagement could make use of any of the earlier approaches discussed (vulnerability assessment, security assessment, penetration test).

Security Review

Verification that industry or internal security standards have been applied to system components or product. This is typically completed through gap analysis and utilises build / code reviews or by reviewing design documents and architecture diagrams. This activity does not utilise any of the earlier approaches (Vulnerability Assessment, Security Assessment, Penetration Test, Security Audit)


How can I get infected by computer viruses?

Drive-by downloads are a real threat. These enable a website to exploit a 0-day vulnerability in your browswer to execute malicious code on your system. Note that sometimes websites are hacked to behave maliciously without the website's owners being malicious.

While browser manufacturers work to fix security problems quickly, the 1534 publicly announced Firefox vulnerabilities are proof that this is a difficult task. Flash is also another well-known source of security problems (currently 1039).

It is also possible that one of your downloads came with malicious files in it. Sites such as CNET are notorious for this.


Shipment tracking displaying delivery information publicly - Is this dangerous?

Not if implemented correctly

Information about my package is something that should be only available to parties of interest, which is in most cases the sender and the recipient. I'm excluding the logistics company itself, as they are not using their external API to query this data anyways.

When a new shipment is added to the system, a unique and unguessable identifier, otherwise known as a Universally Unique Identifier (UUID). Here's an example UUID: b5830ea7-1007-4830-9c30-1dd95be968af

The UUID of the package should then be distributed to the sender and the recipient. Forwarding to the recipient is either done by the logistics company, or by the sender, depending on how it is set up.

The only way to access tracking information is by having this UUID. Since the UUID is 128 bits long, the chances of an attacker guessing a UUID at random is negligibly small.

How to not implement correctly

Of course, the far more interesting scenarios is what happens if it's not implemented correctly. I've once encountered a post service, where in order to get access to the tracking information, you had to enter your address and - I quote - "In order to verify your identity, you need to submit your last name". Because, as we all know, last names are very secret information not known to the public in any way.

In general, it's not a good idea to implement a system in which the only method of verification is to query publicly available information. The possible attacks were described pretty well in your question anyways.


Does KDE System Tray Extra Items "Clipboard" have the same security threats as the system clipboard?

All processes running as your user can read the contents of your clipboard and modify the contents. The KDE clipboard, called Klipper when I last used KDE, also stores previous clipboard history. It stores it by default in a text file. This means that the contents can be recovered from your hard drive by a forensics examiner or malware. You can disable this functionality however, causing it to only be stored in memory. All processes running as your user can still read and modify the clipboard, of course. If malware runs as your user, it has the same abilities you do. Always remember that.

With your system clipboard, the following is possible:

Processes running as your user can read the clipboard contents
Processes running as your user can modify the clipboard contents

With the KDE clipboard, the following is possible (by default):

Processes running as your user can read the clipboard contents
Processes running as your user can modify the clipboard contents
Processes running as your user can read your clipboard history
Processes running as your user can modify your clipboard history
Processes running as root can read very old deleted clipboard history
Forensic examiners / people with access to the drive can read very old deleted clipboard history

The last two bullet points can be disabled. When I last used KDE, this was possible by setting a limit to the history size. When the size is set to unlimited, it will save it to a text file on the drive. When the size is a numeric value, the history will be stored in memory only. You might also have to set it to not remember history across reboots. Or something like that.

I would like to note something however. It sounds to me like you are under the impression that individual applications are able to provide you with security against other programs which runs as your own user. If you indeed are still under the impression that you can protect your system from things like keyloggers running as your user, it is time to be disillusioned. Everything you type can be recorded by programs running as your user. Linux provides inter-user isolation, not intra-user isolation. This means that your browser, if it is compromised, can keylog that user. I've talked about this a bit here and here, and there is an excellent writeup about the problem of assuming intra-user isolation.


Application does't connect to Charles proxy

A common problem with mobile applications and making use of proxy software, such as charles, is that the application may be using "certificate pinning" to prevent proxied interception of the traffic between it and the server.

The easiest way to ascertain this would be to ask the application developer if they're doing that and request a build with that feature disabled to make testing easier (I'm assuming here you're acting as a security reviewer for the app.).

If that's not possible, something like Android SSL Trustkiller can be used on a rooted device to remove the certificate pinning and allow interception.


In such cases I prefer to remove viruses by using a live system like ubuntu for example. This has the upside that the virus isn't curently executed and can't block your effort to remove it.

The process I usually follow is this:

Reboot Host with Linux Live CD
Mount Harddrive
Delete Files manually (if location is known)
Install a Antiv Virus software that runs under linux like clamav for example
Download current anti virus signatures
Scan the whole disk for viruses

Then reboot...

// This is not about trying another anti virus programm it's about running a anti virus application without running the compromised system. This is done because many viruses come with a rootkit or other mechanisms to protect themself from being removed but these mechanisms don't work outside the infected system. This is why I suggest to perform a anti virus scan outside of the system not because of the anti virus scanner itself.


process::start will start the process under the context of the process thread, try using token::run cmd.exe


Prepare for effects of Data Loss Prevention

If you know what vendor and/or solution was chosen, I would check their docs.

One key thing is whether this is a network based DLP solution (in which case, you could check the docs for BroIDS to see how they conceive of DLP), or a local agent based one (i.e. some extension to an antivirus solution).

On a very basic level, a DLP solution will look for either keywords, or content hashes (e.g. sha256 digests) to identify 'sensitive' data that should not be allowed to leave your control/area of visibility.
As usual, it is more complicated than that, but that's the very, very basic functionality you should expect.

In theory at least, DLP shouldn't prevent you from accessing something (that's a job for ACLs and other access control mechanism), it is more meant to prevent you from storing the data in bad or unauthorised places (e.g. sending yourself or others passwords, credit card data, proprietary code/information, etc).

There are generally ways around DLP if you really, really, want to find them, but if your DLP solution isn't allowing you to do your job, fix the solution, don't work around the limitation.


Why do we need the refresh_token OAuth flow?

Because you are not supposed to know the the credentials!
If you allow users of your app to use their CloudDrive with your app, they login to CloudDrive using credentials. You never get the credentials!
When a access token is only valid e.g. 15 minutes, your users would need to enter their credentials every 15min. Users don't like this!

If you wonder why there are different access and refresh tokens and not only one token with long validity, check this answer!


How do GnuPG smartcard generate reliable random data?

Almost all - if not all - smart cards have a true random number generator (TRNG) on it. Most often the TRNG depends on thermal noise or clock drift, but other entropy sources are possible. A more technical evaluation of this can be found e.g. here ("Sources of Randomness in Digital Devices
and Their Testability by Viktor Fischer"). For a longer set of options, have a look at the "hardware random number generator page on Wikipedia. Which one is implemented depends on the specific model of smart card that you are using. It may be hard to find out because commonly this kind of info is hidden in technical documentation that you may not have access to.

The entropy generated by such a TRNG are commonly whitened and / or fed into a CSPRNG before they are used by the OS, applications and / or libraries on the smart card. Usually the RNG's are validated against FIPS 140-2 or AIS31 (German BSI), possibly as part of a Common Criteria certification. The certification of the TRNG / CSPRNG is commonly mentioned in the data sheets of the specific processors and the certification may indicate the precise TRNG that is used.

In your case undoubtedly either a whitened TRNG or a CSPRNG seeded from that TRNG is used for generating two primes of half the key size for your key pair. This requires a lot of randomness. How much entropy and randomness is used depends on the implementation and possibly how much luck the implementation has on finding the primes.

Note that Linux will nowadays also use randomness on chips that support the RDRAND implementation specified by Intel and copied under their agreement by AMD for their Ryzen chips. Because not everybody trusts this kind of random source it is common to mix in entropy from other sources. Other CPU's such as VIA's Eden processors have sported other chip based solutions. Motherboards often contain a TPM chip as well, which is commonly based on a Smart Card design, and sports the same kind of hardware TRNG.


Yes. One built-in way is the "WiFi tethering" functionality, where you share your 4G internet connection over WiFi.

Another possibility is that some app or malware is being used to proxy network connections through your phone.


sensitive data temporarily stored, then redacted: PCI compliant?

The simple answer is no - that would most likely not be complaint with the requirements in PCI DSS. Sorry.

You may get two types of payment card data, the 15/16 digit cc numbers (PCI calls these PANs) and the CCV2 from the back of the card (This is a form of sensitive authentication data or SAD).

You can not store plaintext PAN in a database (ie on non-volatile storage) - it does not comply with Requirement 3.4 - Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches ...

Of course, you could have a long debate about "stored" and how many seconds something is on disk before it is "stored", but most assessors would equate any disk storage as stored (and also check log files). NB: If the DB is in RAM then it's not stored.

Additionally the receipt of PAN by "chat" can be problematic. If chat is a web app over TLS then that's OK. If it something like IRC or Skype then you have a problem with Requirement 4.2 - Never send unprotected PANs by end- user messaging technologies (for example, e- mail, instant messaging, SMS, chat, etc.)..

Hope this is helpful.


How can I secure the usage of root access on android, given that I have regular updates?

You can easily do this by being a good, secure user. Follow the basic tenants of security, and be careful of what you install on your phone. After all games are great, but not when they're really viruses. Since it sounds like you're really going for a super secure phone with data archiving and backup, don't install something unless you KNOW it's safe, and keep as few applications as possible on your phone.

After all you if you do the work, then you've done the work. You look like you're well on your way to making a secure, archival-able phone image for yourself. Just in case maybe some anti malware apps aren't a bad idea so you can be sure to reset accounts from another device if it does get compromised.


Is it secure to use a custom written Php extension for handling + hashing (db) keys?

A PHP extension is just compiled code. If the attacker can see the compiled code, then he can, indeed, decompile it. A key stored in compiled code that the attacker can see, cannot be considered as really secret. Otherwise, DRM would be a solved problem.

Storing the key in a "restricted directory" is a good idea (you don't want the key to be retrievable with a simple subverted GET); using a custom extension and putting the extension DLL itself in that restricted directory won't offer substantially more security. That extension would be the aggregate of the key, and the cryptographic algorithm which uses the key. It is sane practice to assume that the attacker already knows the algorithm (that's Kerckhoffs's principle), so you are back to storing the key in that directory.

Therefore, I would advise against the custom extension, because it does not bring security benefits, but it adds complexity (and complexity is bad).


Is using a local DNS cache server more secure than using a DNS server from a router?

Confidentiality standpoint: Not much really, it does combine your requests with others behind the device, and won't be making them as often as if you were doing it uncached.

Availability standpoint: if a site stops responding to DNS requests sometimes the DNS cache can maintain those requests for a long time (depending on the cache ttl.)  Conversely, if a site is using DNS to perform load balancing or failover, you might be impacted if the site goes down and they switch to another IP for the host behind the name.

Integrity standpoint: Cache poisoning is a risk, you might be succeptable to it currently (or in the future.)  It could also be used by an attacker, if the device was compromised, to redirect DNS requests to a hostile service.

None of these reasons are huge negatives, you can have all of these things applied at almost every layer of your network.  Even Firefox has a DNS cache believe it or not.  If you have the need, I'd use one.  Just follow good security discipline while managing it.


I want to filter Snort rules by date written

These sources do not necessarily include any sort of "date stamp" in the rules though such information could be included in the msg field of the rule options.  You may notice some URLs in the reference field contain dates but this info is not going to be populated sufficiently to rely upon it.  I don't know of any sites/systems/tools that may help and the only suggestion I have is painful...

Starting with the earliest rules you want to evaluate and working up the latest rules, essentially you want to diff from one version of the file to the next which would yield when rules was added/updated/deleted.


Are there different characters that appear exactly the same in browsers' url lines?

But can a url look exactly the same as a legit one in the address bar, while actually being a different url?

Yes, that can occur. It's an advanced phishing technique known as IDN homograph attack.

Homographs (or homoglyphs) are characters that look very similar or even identical. When browsers started supporting internationalized domain names, it became possible to display non-latin characters in URLs, so you could theoretically mix different languages in one domain name.

Can you tell the difference between these?

http://exаmple.com/
http://example.com/

(The first a is actually cyrillic.)

As a response to homograph attacks, browser vendors have established their own IDN policies (e.g. Google Chrome, Mozilla Firefox). They mitigate the problem mostly by blacklisting potentially confusable characters and displaying URLs with non-latin symbols as Punycode under certain conditions. That's why your browser will display the first URL as http://www.xn--exmple-4nf.com/ when you visit it.

Converting potentially misleading URLs while maintaining usability (e.g. you would still want to display a literal ä to someone in Germany) has turned out to be somewhat elusive which is why even in 2017 there are still new homograph attacks being reported.


How do I know that the request and response is using encryption protocols in burp suite?

This depends on the tool you are using within Burp:

Site map - HTTP and HTTPS URLs are shown separately in the tree
Proxy - There is an SSL tick box in the table
Repeater - The target URL will show HTTP or HTTPS
Logger++ There is an SSL tick box similar to Proxy

Burp does not show the SSL cipher suite used. You can use the SSL Scanner extension in the BApp Store to scan for SSL vulnerabilities.


Is it insecure to provide a hash of an AES password?

For password-based encryption, you need to:

transform the password into a key suitable for the encryption algorithm (a process called key derivation);
use that key to encrypt the file.

Assuming that everything about the encryption phase was done properly, and the used algorithm is not weak, then the most direct attack route is the password: the attacker will try potential passwords, applying key derivation then decryption, to see if the result "makes sense". The important point here is that the attacker does not need to decrypt the whole file to see if it looks like the expected cleartext or not; for instance, if the attacker infers that the file is a JPEG picture, then he just needs to decrypt the first four bytes to see if these yield the expected starter sequence for such a file (FF D8 FF E0). Even if the honest user wants the complete file, and thus will need to decrypt it whole (implying I/O for reading the file and writing it back), the attacker is in no way constrained to do the same during his attack.

Therefore, you MUST NOT assume that the whole-file decryption speed makes the attack slower or faster. In that sense, providing a "fast" test for password correctness will not make things easier for the attacker either.

However...

You must take care to do things correctly. First and foremost, the easiest way to design a secure format for password-based file encryption is to use an existing format for password-based file encryption, that has already been designed, analysed, implemented and tested. A reasonable candidate is then OpenPGP, and (in particular) its open-source implementation GnuPG.

If you still insist on doing your own design and then implementation, then you must understand that the core of your security will reside in the key derivation process, also called password hashing. There is a lot of theory and practice on the subject, so I suggest you start by reading this answer.

Now, if you got your password hashing right, with all the iterations and the random salts, then you could envision a process where the password is derived into a key K of, say, 256 bits (32 bytes). Then split that key into two halves K1 and K2 (128 bits each). Add a copy of K1 into the encrypted file header, to test for password correctness; and use K2 (not K1 !) for actually encrypting the file. This is safe as long as the password-based key derivation function is secure as a key derivation function.

Of course, if you need encryption, then (presumably) there are attackers, and attackers are, on the whole, known to be naughty. They don't play by the rules. Most notably, if they can see encrypted files, then chances are that they can modify encrypted files. To reliably detect such modifications, you will need a MAC, and then things become complex. Potential for catastrophic design error is high.


As a matter of fact PHP includes a function to check the validity of a provided address.

http://php.net/manual/en/function.filter-var.php

http://www.php.net/manual/en/filter.filters.validate.php

Ex: filter_var($_POST['from'], FILTER_VALIDATE_EMAIL) ? send() : die("You murdered me. D:");


How to generate a highly unpredictable random bytes

No, sorry, your generator is awfully bad. You seed it with values which do not have much entropy (the PID fits on 16 bits...) or are highly guessable (the "current time" is not exactly a secret value, everybody can know it with remarkable accuracy). And the generator hiding under rand() is known to be breakable (it depends on the actual operating system, but many system use a linear congruential generator which can easily be inverted).

You will get something which vaguely looks randomish at first sight, but will not resist successfully attempts at cracking it, i.e. predicting future output of the generator. Resisting cracking attempts from smart attackers is all what security is about. Your generator might be appropriate for some non-security-related usages, though (although rand() is known to be quite bad at those too).

For correct random number generation, you need:

an initial seed with enough entropy;
a cryptographically secure PRNG which will expand that seed into a long stream of bytes which will be indistinguishable from randomness (even in the eyes of a smart, powerful individual with big computers who is intent on predicting the next random byte).

The initial seed must come from some hardware events ("physical" randomness), because software is, down to the transistor level, deterministic. The operating system is in ideal position to gather physical events (that's its job, after all). Therefore, use the OS. This means:

On Unix-like systems (like Linux, FreeBSD, Solaris, MacOS X...), use /dev/urandom (not /dev/random; see this answer for details).
On Windows (Win32), call CryptGenRandom().
On Java, use java.security.SecureRandom.
On .NET, use System.Security.Cryptography.RNGCryptoServiceProvider.


Actually, code signing is simply a way to validate that an app came from the app store. It has nothing directly to do with who the app is from or what intent the app designers had in mind.

The issue of malware being introduced is mostly the result of it not being caught by Google's filters (see wiki for details authentication procedures).

Moreover, code signing itself isnt really enough as vulnerabilities do exist.

In addition to everything you stated, code signing also allows the developer to release updates to their app without having to 're-authenticate' themselves [fully] to Google. Being code signed also means you are (in theory) easier to physically track down in case you did upload malware, thus code signing acts like a forensic fingerprint of sorts (I am oversimplifying the issue/details).

Bottom line is the original developer can do nothing but watch and report malicious interpretations of their app (not to mention, many 'legit' apps are simply exploitable).

If you did 'completely rely on Google' that would change legal obligations and most likely drive app costs up as Google would now have to veht each app vigorously to avoid lawsuits.


Contract requires me to work with sensitive IP, severe penalties for loss of data to 3rd parties. Some protection pointers please

If the potential compromise of the data can truly cause damages in the billions, then in my opinion you need to seriously question the advisability of taking this data "on the road, visiting clients worldwide."

Is there some business reason why this client requires you to take this data all over the world? If not, then don't do it.

You do understand that every time you go through customs you may be required to turn your laptop over to a customs agent for inspection don't you? Has your client agreed in writing that it is OK for you to give access to third parties?

Why are you taking this data to other clients? If this is not something your client requires, don't do it.

If you were doing work for the federal government, they would not permit access to their controlled data in anything other than a controlled environment. In fact you could end up in jail if you took certain types of data off premises and particularly out of the country.

Come to think of it, why is this data on your laptop at all? Could you not do your job by having it on a thumb drive or external hard disk that you kept locked in a safe in your home?


How can I design a password reset function, which does not reduce security for users who can remember their password?

Have a user-configurable boolean value for "reset allowed".

If you have their e-mail / some out-of-band means of communicating with the end user

When the user clicks the "I forgot my password" link, if "reset allowed" is true, send a password reset link to the e-mail account associated with the user account. Make sure you use an e-mail service that first attempts end-to-end encryption (so that, if their mail server supports that, the link never gets sent in plain. And if their server doesn't support that, they aren't denied the link).

Rate limit the number of times that e-mail can be sent to the same account (e.g. 2 resets per day) so someone can't use that to spam the account. Don't let the user know if an e-mail has been sent or if the account they mentioned even exists.

If they don't click the password reset link, nothing should change. If they click it after a certain timeout period, or if between the e-mail being sent and the time of it being clicked "reset allowed" has been set to false, nothing should happen.

If you don't have an out-of-band means of communication

If "reset allowed" is set, use a challenge-response mechanism such as user-configurable security questions. If they answer the questions correctly, allow them to enter a new password. You might also want to consider hashing the responses.

You could, of course, also use something like TOTP, but chances are if they don't have the password, they also won't have the key needed for this.

Either way

Conduct the entire exchange over an encrypted channel. Unless you're trying to stop the NSA from stealing credentials, SSL should be enough.


Difficulty of breaking private key password

The long and short is: it depends!

A long, strong, random passphrase encrypted properly with lots of iterations is very safe

unless there's a flaw in gpg somewhere (which is possible, of course), very safe.

A weak passphrase is always unsafe.
A small number of iterations on encryption makes the area of "weak passphrase" bigger, and the area of "strong passphrase" smaller.

Let's experiment, so you can see for yourself!

We'll more or less start with the Ubuntuvibes article Recover your gpg passphrase using John the Ripper.

Create a GPG key, nice and default, with a weak passphrase to validate the technique:

gpg --gen-key

Follow the defaults FOR THIS DEMONSTRATION, but name it "CrackingTestDefault"

To change the passphrase, you can simply use the following and then re-export to try again!

gpg --edit-key <keyid>
  passwd

Now, export the test secret key

gpg -a -o ctd.asc --export-secret-key CrackingTestDefault

Download and compile John the Ripper 1.8.0-jumbo-1 or the latest when you read this - configure and compile.  Or just use Kali linux.

Now extract the important bits into John's format using a John the Ripper helper app that came with the Jumbo version

run/gpg2john ctd.asc >ctd.john

Now let's just try the default mode and see what happens

IF your weak password was TestTest, like mine, then you found it nearly instantly!  Let's show the password

run/john --show ctd.john

See our password of TestTest?

Reset John's list of cracked passwords, the "pot", and do something different just to show what people are talking about when they say a password will take days (on an 8 core CPU)

mv run/john.pot run/john.pot.found1

Now let's try incremental mode, lower case only, and see what happens
    run/john --format=gpg --mask=?u?l?l?l?u?l?l?l ctd.john

Let it settle out for a few seconds, then check your CPU use and hit a key.  If you compiled John correctly, it's maxed out all your CPU cores, and it's still going to take a few weeks, because it is - STUPIDLY - trying every single combination.

Note the speed - on my 8 core box, it's getting right around 50,000 guesses per second.  That's 129.6 BILLION guesses every 30 days, and a targeted attack against a GPG passphrase is likely to be worth quite a lot more than most password cracking exercises, so expect more than a single CPU running for more than a single month!

Let's try a real rule

Press Ctrl-C and stop it.  Mask attacks are fine for very small keyspaces, or very fast hashes.

Try a real attack - a rules-based wordlist attack!

run/john --format=gpg --wordlist=run/password.lst --rules:Jumbo ctd.john

It shouldn't take long to find TestTest, or Test7, or quite a few other word based passwords.  Play with it!

Rule #1 - Use a long, strong, random GPG passphrase.

If your passphrase is weak by the definition of cracking attacks
Let's try something else!  Let's try changing how GPG protects the key!

We're going to encrypt the key with AES256, use a SHA-512 digest, and drastically increase our iteration count.

Change the password to Chameleon98 now:

gpg --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-cipher-algo AES256 --s2k-count 70000000 --edit-key CrackingTestDefault
   passwd
       enter your old password, then Chameleon98, the new password, twice
   save

Now, use the previous instructions to extract it to ctdcham.asc, create ctdcham.john, and attack it.

If your system is like mine, the cracking speed is now about 32 guesses per second, instead of 50,000 guesses per second; more than three orders of magnitude slower.

Now, unless you want to wait for the hours or days your machine will take to go through the entire John wordlist with that ruleset, you can create a file called cham.lst, with a single line that has the word

chameleon

in it, and use THAT as your wordlist with the Jumbo rules based attack above just to see if Chameleon98 is vulnerable to the Jumbo ruleset.  You will, in fact, see that John the Ripper will use the base word, and it will finally get to a rule that capitalizes the first letter and adds 98 to the end, cracking it - but now it takes quite a lot longer.

WARNING: the Jumbo ruleset is not the be-all or end-all.  See some of the rulesets that come with Hashcat which are much, much longer, and Hashcat has rules John doesn't, too, though as of Jan 2016 I don't think Hashcat has a mode for GPG in specific.

WARNING: Whenever the gpg attack is ported to GPU, the attack may get a MASSIVE speedup.

Try decrypting a file, too - note there's a second or two's pause (more on a slower CPU) after entering your passphrase.  Cracking takes 1500 times longer; well, normally use of the passphrase ALSO takes 1500 times longer.  However, unless you're decrypting lots and lots of files, you can probably afford to take a couple seconds after entering your passphrase, in exchange for making attackers spend more resources and/or test a smaller keyspace.

Rule #2: Use the --s2k* options when generating keys, AND when changing passphrases!!!

Feel free to use Luis Rocha's JtR cheat sheet to play around further.


Can a employee steal a company's SSL certificate private key?

Is it possible to a rogue employee to just login in a company server
  and steal the private keys used to secure SSL connections?

Yes, except when it's hard, or when it's impossible.

  Is it as easy as copying a file?

This is where the gradation comes in.  There are a wide variety of security levels, some of which I'll describe here from easy to hard:

In the easiest case, yes, the private key is a simple text (PEM) file, and may not even have proper file protections*
Or the key file might be stored with restrictive permissions.  Now the employee not only needs to be on the server, he needs to have the appropriate (Administrator or application) privileges to copy the key.
The key file might be password protected but automated.  This usually just means that in addition to the key file, the employee needs to find the config file with the password stored in it and steal that too.  (See also "java keystore changeit"...)
The key file might be password protected and the key entered at runtime by a human operator.  In this case, the password cannot simply be stolen from the system.  Of course, your employee might be an operator...  Also, in practical terms, very few servers are run to require human intervention upon restart.
If I recall correctly, IIS used to be able to import the key into a keystore that was not exportable by users, but would allow use by services.  Such things can generally be worked around with enough privileges.
Finally, if a Hardware Security Module (HSM) is used, that is designed to protect the keys even from the Operating System itself, to allow their use via cryptographic operations without exposing the keys to the computer hardware and software.  In this case, the employee will probably find the key impossible to steal.

  Here, I want to know how easy is to an insider get the private keys.

It's going to depend on the site, but in general, my experience has been that most sites store the key with nothing more than file permissions to protect it.  The general sense is "Well, if someone breaks into the server, they've already gotten everything, and we'll need to issue a new key anyway when we recover."  Of course, this ignores

the gap between compromise and discovery, and
the potential use of a private key to quietly read traffic in the meantime.

The shift towards ephemeral TLS ciphers is slowly closing that second gap, rendering the private key far less useful (snooping is often more valuable than impersonation; impersonation can be achieved in other (possibly simpler) ways).

*C'mon, guys, don't pretend you haven't seen a dozen poorly secured Apache configurations where the keys were left world readable.


To what extend can a DOS attack succeed even if it was detected?

As long as the DOS attack can consume more resources (network bandwidth, compute power etc) than the target can supply, then it will succeed, despite being identified.

Filtering is very difficult - you require a lot of bandwidth, and a way to separate good from bad traffic. If you filter everything, then you cause a DOS on yourself anyway.

This is why a DDoS has such an impact. It is possible to launch orders of magnitude more traffic than the target can cope with. The only solution in these cases is to use a DDoS mitigation partner - and even there, there is always some impact as they enable rerouting, configure scrubbing rules, tune these rules etc., and as before, if the DDoS gets big enough it will also knock the mitigation provider off the Internet.


I want to create a website, what aspects of security should I really care of?

When you're dealing with WordPress, the most important thing is to do their updates very often. WordPress brings out security patches every few days-weeks and you should think about the workflow of doing updates on a regular basis.

The most common vulnerabilities when dealing with web development, are things like SQL Injections, Cross Site Scripting (XSS), wrongly implementing authentication and session management, Cross-Site Request Forgery (CSRF) and things like this.

You can find more about these topics on the internet, I would suggest you take a look at the top 10 OWASP vulnerabities. OWASP (Open web application security project) has lots of resources available for you to learn about vulnerabilities and how you go over fixing them. This blog articles explains the current top 10.

If you want to learn more about security by design, which is the topic you should really explore more, you can take a look at the OWASP Security Knowledge Framework. This framework gives you a lot of information and examples about secure programming in several languages.

You should indeed use a SSL certificate, not just because it gives proper information to your users, but because it makes the connection between your website and your users secure. You can read more about SSL and why you need a certificate on this website.

  With the server, should I get support and security or some kind of similar service?

Most services that let you rent servers, have a managed solution. They are more expensive but if you are new to security and securing servers, this is your best option when you are in production. Obviously I would recommend you setup your own server and learn about security along the way, but not in production.

To add on to the subject of server security, this answer does a great job at explaining the difference between you as a web developer and system administrators:

  But it's a different thing when you rent a virtual server which
  provides you with a naked operating system (or not even that) and
  expects you to set up everything on your own. In that case you are
  responsible for updating everything. When you require this for your
  project, you should consider hiring someone who knows how to harden a
  server properly, who knows which components need to be updated and how
  this is done. But the person you are looking for is not a software
  developer. It's a system administrator.


Email "FROM address" is changed to an unexpected email address

TL;DR: This is probably a feature of the mailing list to prevent DMARC from failing.
It is well known that DMARC does not survive DMARC+SPF on mailing lists, as to prevent SPF tests from failing the list server must change the envelope sender to one from their own domain.
DMARC+DKIM might survive, if the message is both DKIM signed and the mailing list does not alter the message body. For e.g. legal reasons a mailing list might want to change the message body to contain some disclaimers or unsubscribe information. In order to get this kind of messages delivered one might create an implementation where also the From header gets rewritten. Also, not nearly everyone DKIM sign their messages, so this is quite a suitable workaround, although it is not following any standards.


Are there any security risks to accepting HTTP/0.9 style GET requests? (e.g. "GET /\r\n")

You could in theory accept any junk. But how do you want to respond to it? If the client sends HTTP 0.9 then you should not respond with HTTP/1.0 or HTTP/1.1 since such a client will likely not understand it. HTTP 0.9 means specifically no HTTP header in the response. This means lack of semantics to express things like Content-Type or Cookie. Given that most applications today relies on providing such information you also need to find ways to express the necessary semantics with such old clients which makes everything more complex.

Apart from that - HTTP is a complex enough protocol already (if properly implemented). Given that HTTP 0.9 is obsolete for more than 20 years and that there is no current and relevant client out there which still needs HTTP 0.9, you essentially add code which will never be needed for a practical purpose. This means that this code will be less tested than the rest and that the chance of critical bugs in this part of the code is much higher than in the rest. And while no relevant client will actually use HTTP 0.9 one can write a client which will do and which might make use of critical bugs inside this poorly tested code path.

In short: don't implement anything which is not needed. This way the code base is smaller and easier to test which results in more robust code. Anything which is not used in practice will result in rotten code which has no practical relevance except to cause trouble, for example by being a potential attack vector.


Is an AIA or CRL useful / required at the Root CA if that Root is used to cross certify another PKI?

The Authority Information Access extension is used to publish in a given certificate:

where a copy of the issuer's certificate may be downloaded;
at which address / URL an OCSP server may be found, which will yield fresh revocation information on the certificate which contains the AIA.

See section 4.2.2.1 of RFC 5280.

Both usages make sense only in a certificate which is meant to have an issuer, i.e. a certificate which is not the first certificate in a validation path. The first certificate in a path is the "trust anchor", aka "the root CA": this is the name+key in which you trust "by definition", not because of a delegation from some issuer. As such, trust anchors have no issuer and no revocation status (they cannot be revoked by some upper CA; at best, you manually decide to cease to trust them). Trust anchors (root CA) are represented as certificates out of tradition but extensions in a root CA make little sense (when such extensions are used, this is often with a semantic which is quite distinct from what the extension usually embodies).

There is a possible confusion which you must learn to avoid: a CA is not the same thing as a CA certificate. A Certification Authority is an entity which has a name (an X.500 Distinguished Name) and a key. That name and that public key can be copied into several distinct certificates. This is common in the situation where two hierarchical PKI decide to "trust each other". Consider two PKI, called (unimaginatively) "A" and "B". Each PKI consists in:

a root CA (called "root_A" and "root_B", respectively), which we can imagine as an offline system with a Hardware Security Module;
a subordinate CA (called "sub_A" and "sub_B", respectively), which is an online system, possibly also with a HSM, and which issues the end-entity certificates;
end-entity certificates.

Each CA, be it online or offline, must publish revocation information on a regular basis, so we must assume that even for the offline CA, there is an online server somewhere, where an adequate CRL is pushed through some manual procedure (or possibly automatically if there is a one-way network link from the root to the online server -- the one-wayness of the link allowing to maintain the offlineness of the CA).

Before PKI A and B decide to trust each other, some certificates exist, with the following characteristics:

The name and key of root_A are published as a self-signed certificate, and a copy of that certificate is available on: http://serverA.com/root_A.cer
The name and key of sub_A are published as a certificate, signed by root_A, with an AIA which points at the URL where root_A.cer is made available. A copy of the certificate for sub_A is available on: http://serverA.com/sub_A.cer
In each end-entity certificate published by sub_A is an AIA which contains the URL on which sub_A.cer resides.
Similarly for PKI B.

Thus, a verifier who wants to validate an end-entity certificate from PKI A follows the AIA extensions to download all required certificates, i.e. sub_A.cer. The verifier may also download root_A.cer but this is hardly necessary, since, for validation to succeed, the verifier must already have a copy of this self-signed certificate. Pointers to OCSP servers (also in the AIA) and to CRL (as CRL Distribution Points extensions) follow the same pattern, although, in that case, the pointer to the CRL/OCSP from root_A is not superfluous (verifiers must check that sub_A is not revoked).

Now comes the covenant by which A and B decide to bind their fates, mingle their blood, and generally be best friends forever. To that effect, PKI A and B will "merge", or at least be linked with what is usually known as a "bridge CA". The point is to allow people who trust root_A to automatically accept the end-entity certificates from PKI B as valid. There are mostly four ways to achieve this:

Root_A issues a new certificate for root_B: the certificate contains the name and key of root_B, but this certificate is not self-signed; instead, it is signed by root_A. Let's call bridge_AB.cer this new certificate. Being issued by root_A, this certificate contains an AIA which points at root_A.cer and the OCSP server which maintains revocation status of certificates issued by root_A.

Since no existing certificate has been altered or revoked or deprecated in any way, people who trust root_B (as a trust anchor) can keep on validating EE certificates from PKI B, as before. For such an EE certificate, the path to validate will be root_B->sub_B.cer->EE for people who have root_B as a trust anchor; for people who have only root_A as a trust anchor, the path will be root_A->bridge_AB.cer->sub_B.cer->EE.

For this process to work automatically, involved certificates should contain AIA extensions which allow the reconstruction of both chains. In that case, it suffices to replace the root_B.cer (on the serverB.com server) with a copy of bridge_AB.cer, but under the name root_B.cer. Thus, the AIA in sub_B.cer now points to bridge_AB.cer, without needing to change any single bit of sub_B.cer. People who trust root_B can use it directly, they don't even look at the AIA in sub_B.cer (at least for path reconstruction); people who trust root_A only follow the AIA and rebuild the path which begins with root_A. Everything is fine.

Replacing root_B.cer with the bridge certificate works only as long as there are only two PKI. If a third PKI C joins them in a ménage-à-trois, a more generic method must be employed: a new certificate is issued for sub_B: that certificate will contain an AIA which points at all the certificates for root_B: the old self-signed certificate, bridge_AB.cer, bridge_CB.cer, and so on. The AIA format allows for containing several URI. That new certificate for sub_B can be published as sub_B.cer, replacing the previous one.
Root_A issues a new certificate for sub_B. Since this new certificate is issued by root_A, it contains an AIA which points to root_A.cer. Let's call sub_AB.cer this new certificate.

At that point, we have an issue with regards to path building. An EE certificate from PKI B still contains an AIA which points to sub_B.cer on server serverB.com. If we replace sub_B.cer with the new certificate issued by root_A (sub_AB.cer), then path building finishes on root_A with no possibility to plug back to root_B: validation for people who trust root_B only is now broken. The generic solution would be to reissue all EE certificates, with a new AIA which points at both certificates for sub_B (the one issued by root_B, and the one issued by root_A). However, mass reissuing is expensive. An alternative way is to "make available" sub_AB.cer to people who want to verify certificates. There is a certificate store in Windows meant for that (called "Intermediate CA"). Even though this certificate will not be referenced in AIA, software should be smart enough to use it where necessary. Since an intermediate CA is not a priori trusted, mass deployment of such a certificate is less problematic than deploying a new trust anchor.
Sub_A issues a certificate for root_B. Treatment is similar to the case 1.
Sub_A issues a certificate for sub_B. Treatment is similar to the case 2.

These four methods are for delegation of trust from PKI A to PKI B, allowing people who trust in root_A to validate EE certificates from PKI B. For a full bridge, the other direction must also be done (people who trust in root_B should be able to validate EE certificates from PKI A). It is not necessary for both bridges to follow the same topology (but the fancier you get, the more confusing the whole thing becomes).

The salient points are that:

Any CA can have several certificates, which contain the same name and key. A given certificate (EE or CA) has a single issuer (the entity which signed the certificate) but any certificate containing the name and key of that issuer can be plugged at that point in the path. Correspondingly, certificate paths may merge (X.509 explicitly prohibits full loops).
The AIA extensions are used to help in path building, by pointing to potential certificates for the issuer. Use of these certificate is not mandatory; mass deployment of intermediate CA certificates is a viable alternative (at least in organized networks which offer facilities for that, e.g. Active Directory servers).
None of this is impacted by policy mappings. It is the other way round: if PKI A and B use certificate policies, and both have their own distinct OID, then the bridge will have to include a mapping, so that verifiers can follow the policies through all paths that the may build.


A practical .NET Remoting Architecture exploit

DoS attacks - Given the cross technology nature of these frameworks (they C#-VB-C...) they generally are hard to secure the connection "ports". Therefore if you can enumerate and find the connection points you can often times flood them or just keep them busy and create a DoS attack by starving the "receiving" end of the framework. It is generally not hard to do, and unless a LOT of care has been put into the architecture and secured properly, then this is a low-hanging fruit.
Resource Starvation Attacks:

a. Proxy Resource Attack - Generally given the proxy schemes schemes implemented by these frameworks, there is generally a loosely bound proxy that is needed that is not explicitly destroyed when resources are set-up and taken-down. This allows for ways that an attacker can script ways to blow up proxy resources create starvation scenarios.

b. Physical Resource Attacks - The serialization mechanisms used to inflate/deflate objects can at several points create physical resource attacks. You can create object bombs - large objects that consume resources extensively shutting down or starving the system; or in the case of recursive xml serialization you could create both processor and memory resource consumption by having xml processing that ties the system up.

Code Injection

a. Mutation - This is where you mutate original code or objects but injecting new code into them. Each language has its own ways and guards to overcome, but generally doable.

b. Collateral - This is where you mutate or inject code into secondary languages, such as inject new SQL into database interactions, or push out new Javascript in web scenarios.


How to send SQL or HTML data over HTTP without triggering WAF rules?

So how can I send these formulas and XML informaiton without triggering those WAF rules? I tried encoding the data but that didn't work.

A WAF is there to protect an application. The application should not need to work around the WAF but the WAF should be tuned to match the expected behavior of the application. This is no different from other firewalls or IDS, which need to be tuned to the expected traffic.
Of course, the application has to make sure that these requests are really innocent even if they might look like SQL or HTML injection to some (dumb?) WAF rule.


Manually monitoring your PC for Java (Oracle) exploits?

Manually monitoring for any kind of Malware is not exactly practical (even on a single computer, let alone in any kind enterprise setting).  Also, the answer to that question will depend on what OS you are referring to.

I'm just going to assume you're using a windows OS.  If you're really determined to conduct some kind of manual search, sort by date modified and look in directories that are common across all systems (system files, current user, program files, etc.).

As far as java vulnerabilities, just keep up to date on exploit notifications and keep your JVM updated.


Signing Keys Without Meeting Somebody

In principle, you can sign any key you want for whatever reasons. Nobody is there to enforce anything, but probably people will realize after a while and distrust you.

You should never sign keys that you could not verify in any fashion. Signing is a statement that you're sure about the other's identity – but how should you?

Regarding CAcert: if you're already able to verify their root certificate (for HTTPs), you can read their OpenPGP fingerprint on their website. If that's fine for you for signing their key, and the fingerprint on the website matches the one you downloaded, do so.

If you're not sure about their root certificate, and it is not included by default in your distribution, you might want to keep the uppermost part of the assurance form, which contains the fingerprints (the assurer is allowed and prompted to hand it to you!). It is not reasonable to assume that somebody is able to tamper with the assurance form the other member printed from their site, and at the same time tampering the CAcert web site.

Certificate Authority in OpenPGP Web of Trust

CAcert is the largest certificate authority in the OpenPGP web of trust, they have a very central position. If you sign and trust it (and thus trust in their methods on signing other CAcert user's keys), you can extend the part of the OpenPGP web of trust which you can validate (usually by magnitudes). Doing so is pretty much the same like adding their root certificate to your browser.

If you do not want to publicly sign their key, you can use a local signature that will not get uploaded to key servers.

My own Opinion

I did sign and trust their key, as I want to take advantage of the huge number of keys I can validate now and potentially put more trust in CAcert's methods of assurance than what most people do at OpenPGP keysignings.


Is Using SSL secure enough to post request login credentials to my backend server?

Sinse you don't see any cookies, means you store user credentials on the client. It means that either you ask user for credentials for every single request, which is a poor usability. Or you have fields for user and password, user enters these data once and they remain in the current page the whole time over multiple requests. If this is true, this is not a good approach. Such sensitive data should be kept as short time as possible, because otherwise there is a risk that somebody else will know them.

SSL (or very probably you use TLS) ensures that nobody else can decrypt the traffic.

On the server side there can be some risks. Normally certificates are installed on a separate server, before the server where the application is running. The way between server with certificate and your application remains unencrypted. If there are no other users in your environment, this is not a big problem. But if there are other users, then there is a risk that some users can read your unencrypted traffic on the server side.


It is possible to turn off the Windows Store altogether via Group Policy.  (Item 5 here)

  This setting can be found in Computer Configuration, Administrative
  Templates, Windows Components, Store.

Once that is done, Windows 8 apps can be side-loaded.  Details here.


How can I protect myself from intercepting messages sent to the server?

You can't. You're running into a classic problem: the user has physical access and there's absolutely nothing you can do to concretely prevent them from modifying things.
You can certainly make it harder for them to attack, for example by using HTTPS with certificate pinning for your network communications so that they can't simply man-in-the-middle the traffic, but if the user writes their own driver to mess with your driver you really can't do much about it.
The strongest protection I can think of on a modern x86 system would be for your to get your code running in an SGX enclave, but this is a rather complicated task that requires a lot of development effort. The sensitive parts of your driver code would run inside of the enclave and a regular kernel-mode driver would talk to it through ECALLs/OCALLs. This doesn't prevent the user from blocking the driver from running though, nor does it prevent the user from reverse engineering the executables on disk and writing their own tool or driver to send requests to your server.
If your goal is to prevent the user from modifying something, then you need to have more privileges and access than they do. But in the case of your code running on their computer, they always have more privileges and access than you do, by design. You can't work around this.


For the first part of the question, you could considere setting up a reverse proxy (Apache or nginx) in front of the legacy apps and have the SSL processing on the proxy. If you have full control on the datacenter, the proxy and the application can run on different machines, if you do not, they should run on same machine for obvious security reasons.

The second part (Google rank) is off topic here.


How would someone attack a not truly random secret produced by a human?

A simple answer is that a human will tend to hit keys in the middle and/or on the 'home row' of the keyboard more and will tend to hit keys near each other together more often (due to double hits). There may also be more 'non-shifted' special characters and number row characters. Numbers and Special characters can capitals are more likely to be grouped (or just appended to) the main 'random' string.

You will therefore get a higher frequency of asdfghjkltyuivbnm, sequences like sw qd l; etc. and more in the format of oipynKJIU8767@~{&$

These can be consciously avoided, but this could from its own patten or have a too even mix (nearly the same number of each type).: dR%6Ni9)lI&6...

This could weaken things somewhat and give the attacker some assistance, but for a long string it's unlikely to be significant. It would also require the attacker knowing it was human generated to they a modified brute force attack

None of my suggestions on frequency is comprehensive and a bit of effort can produce a very random string.

Personally I often use a password generator then change a couple of items or to remove any link to the pseudo-random seed (a bit paranoid really).


Is the following PayPal Vulnerability a design/implementation flaw?

The vulnerability is in the fact that the application enforces second-factor auth verification client-side.

That is, the service itself does not require two-factor authentication, ever. But it is willing to process two-factor authentication if requested, and if the client app learns that account has two-factor enabled, then the app will attempt verification.

But if the client doesn't find out (or is modified to not care), then it won't request verification. And the backend service won't complain either.

The vulnerability can be summed up thusly: "Two-factor authentication is not enforced." Whether that's a design flaw or an implementation flaw depends on whether they meant for it to be this way or whether it was an accident. They haven't said either way.

Note that this vulnerability was discovered back in August by Joshua Rogers. The attribution you've supplied is incorrect. http://blog.internot.info/2014/08/paypal-complete-2-factor.html


Enabling firewall for the IPv6 tunnel on Windows 2008 64-bit

Not entirely sure why the answer from @balgan had a downvote, but to expand essentially I would recommend the same thing which is to use the windows firewall which ships with Server 2008 to protect that host and block access to services over the IPv6 tunnel interface.

If you've not running the firewall already to block IPv4 connections, you could add a custom rule specifically for the IPv6 address that you've got assigned to the host via the windows firewall management gui.


Why does Google still use SHA-1 for securing API keys if its been compromised?

Im summary: SHA-1 has various use cases and while some are considered broken others are not.

You are mixing apples and oranges:

  ... them warning against using SHA-1.

They advice against SHA-1 to be used as hash in storing passwords. But this is not specific to SHA-1, it is even a bad idea to use SHA-2 for storing passwords. See also How to securely hash passwords?.

  They have even purposefully cracked it in 2017.

They have shown a collision attack. This is not "cracked" in the general sense but it shows a specific weakness and affects only use cases where collision attacks can be a problem.

  ... then why when you restrict google cloud API keys for android apps, you use a SHA-1 fingerprint of your android app?  Seeing as how its trivial to fake a package name (the other required detail to identify your app) you're only left with a security method thats been already cracked.

If you want to reuse an API key which belongs to the app of another party then you have to mount a pre-image attack and not a collision attack. Pre-image attacks against SHA-1 are not feasible so far.


How do you stop a hacker with no IP and a dot for their HOST

You start by figuring out what's going wrong with your logging.  Everyone on the Internet has an IP address -- it's a necessary condition for connecting to any other computer out there.