How safe is a 3.5mm headphone jack on a laptop?

No. The FBI agents thing is more likely; that's at least possible to imagine a scenario whereby it could occur.

The 3.5mm port is an analog port for audio. A malicious device can't impersonate anything, because it has no way to identify itself as anything (fraudulently or otherwise). Anything sent down to the computer would just be received as... microphone input. The vast majority of laptops and many desktops have microphones that are connected 24/7, and send signals whenever there's powerful-enough sound waves to create a detectable electrical impulse. Nothing comes of it.

The scenario you describe is not relevant to the 3.5mm port; that's about the question of "could somebody build a malicious device into a microphone" and has nothing to do with the jack, per se (mics can also connect via USB, Lightning, Bluetooth, and a bunch of other stuff). The answer to that is, technically, yes, but they could do the same thing with your mouse, your monitor, your case, your flashdrive, your webcam (most of which have mics, not that this matters), your DVD drive, and anything else. Ironically, it would not work the way you describe it; the computer doesn't push any power out the audio jack unless it's trying to play audio out that jack, so your device wouldn't get any juice most of the time!


Can a compressed archive be constructed in a way to extract into system folders?

is it possible to trick compression utilities to extract files to a location not specified by the user?

Yes, it's possible. And is a know problem with a catchy name: Zip Slip. It depends on the particular implementation of your extraction utility: how the extraction routine parses the destination file name.

If your unzip utility is outdated, you can be affected. On Windows, if you extract the files on D: instead of C: you should not be affected.


Spoofing Login with facebook from another app

I believe you need also the App Secret to successfully issue a request. You should not store both hardcoded in your app. Based on your description it seams your app issues the request directly to fb server, which i think its not recommended instead you should have a server which work as intermediary and stores you app secret and app access token.

for more info checkout this page:
https://developers.facebook.com/docs/facebook-login/security


Is this "security update" from security-update@amazon.com an advanced phishing scam or a real security measure from Amazon?

I called Amazon and the representative verified that no such email had been sent by Amazon. This is may be a phishing attempt. The original email seems (according to other reports) to include link formatted "Amazon.com" text, which may be a link to a fake version of the site. I can't see this in mine, possibly due to a measure by Yahoo Mail to remove such link formatting to avoid phishing attempts like this.

Edit: As mentioned in comments, there could be a valid strand of this email and a duplicate malicious strand, with the false link formatting for phishing purposes.

Beware there are people claiming this is a legit email, while I can't 100% deny the possibility, I'm skeptical: It would be smart for the sender of phishing mail to write that it's a real email on related web pages such as this one. Also note that the directions in the email don't make sense. The title of the email is "Your password has been changed" - but my password was still active.

Update:

I commented skeptically toward answers here claiming the email was legitimate, however I might be pulling the trigger prematurely. My answer assumes:

The customer service rep I spoke to was fully informed.
No identical legitimate email had been copied in the past, or even in the past 24 hrs and false link formatted duplicates were sent out by a malicious user.

Both are possibilities to consider.


Why do login systems tell users an email address is not in the system?

This is one of the trade offs between security and usability.

In a perfectly secure world, you would get a message saying that the login information is incorrect (and not specify the user name/password field), leaving an attack unsure of which field to change for the next attack.  From a usability standpoint, it is a much nicer error to see that the user has typed a password or email address wrong, so the user knows which to check.

Of course, Google's design (Microsoft's Outlook.com is the same way now) means they can't really tell you that either is wrong, just one or other other (by them asking for email and password separately).


OpenSSL_encrypt returning an incorrect cyphertext?

To quote from the php docs' comments, emphasis by me:

  In plain english, the buffer must be padded up to blockSize. If the
  buffer is already a multiple of blockSize, you add an entire new
  blockSize bytes as padding.

  The value of the padding bytes MUST be the number of padding bytes as
  a byte...

  So 5 bytes of padding will result in the following bytes added at the
  end of the ciphertext: [ 0x05 ][ 0x05 ][ 0x05 ][ 0x05 ][ 0x05 ]

  Hope this saves someone else a few hours of their life.

Your message is one full block. Thus, the implementation of openssl_encrypt adds a padding block. This is why the second half of your result (which you did not expect) neatly decrypts to

0x10101010101010101010101010101010

using plain aes with that key - it is a padding added by the implementation, because plain aes is not the same as aes-cbc.


From the information you have provided, the issue is most likely due to a routing problem. You forgot to mention whether you tried it with Genymotion? If you did, the VM is in NAT config and may not be connecting properly.  Have you installed all three components required for MITM to work? To set it up with google cloud instance, did you try this documentation?


I also understand that it is important to rotate public encryption keys since after a number of uses, the private key becomes mathematically exposed with fewer computational cycles.

Well, you understood wrong. This is a widespread myth, but myth nonetheless. Keys don't wear upon usage -- especially not signature keys. Keys used to require regular rotation, but that was back in the days before computers, when cryptographic algorithms had to be done with a pen and paper, or possibly some assembly of whirring cogs. Times have changed.

A decent signature algorithm is supposed to remain safe even if you produce a billion of billions of signatures. An algorithm which does not achieve at least that level of security is said to be "broken" and cryptographers shun it. RSA (used properly, i.e. as explained in PKCS#1) is not broken.


Lots of failed outgoing sshd attempts. Am I hacked?

My guess is you (or someone else on your server) is doing SSH proxy tunneling and connecting to stackexchange or another site using gravitar, and for some reason those connections to gravatar were timing out.  I do not think my home server is hacked and I see similar messages in my auth.log, but only on days when I was using the SSH proxy.  The messages are on my_home_computer when I'm using a proxy from a different computer that was setup by ssh -fND localhost:12346 my_home_computer -- granted my entries are logging IP addresses like:

Mar  6 14:33:57 my_home_computer sshd[17500]: error: connect_to 173.192.82.196 port 80: failed.

My guess is these messages correspond to the lines in the side using the proxy that say:

channel 6: open failed: connect failed: Connection timed out
channel 4: open failed: connect failed: No route to host
channel 2: open failed: connect failed: Connection timed out

EDIT: Further testing, confirmed this suspicion.  Starting the ssh tunnel with the verbose flag set (-v):

ssh -vfND localhost:12346 my_home_computer

and trying to connect to a bad IP address (10.11.12.13) that eventually times out, on the timeout (visible in the web browser with a "The connection has timed out" message), the output of the terminal that started the ssh tunnel will show:

channel 2: open failed: connect failed: Connection timed out
debug1: channel 2: free: direct-tcpip: listening port 12346 for 10.11.12.13 port 80, connect from 127.0.0.1 port 34199, nchannels 10

Meanwhile, watching the output of auth.log at the same time with sudo tail -f /var/log/auth.log the following log entry will pop up:

Apr  7 17:38:03 my_home_computer sshd[23789]: error: connect_to 10.11.12.13 port 80: failed.

TL;DR: Just harmless web browsing and ssh warning you that while browsing some HTTP requests timed out or had no route to host at various points in the day.


What does this Https - "not fully secure" warning mean?

In a nutshell, it is saying that while the core of the page is using https (secure) to get that information to your computer, that (secure) page references insecure elements (like pictures and possibly scripts).

Attackers can't directly change the original page, but they can change the insecure elements.  If those are pictures, they can change the image.  If those are scripts, they can change those, too.  In that way, attackers could change what you see, even though the core page was 'secure'.

As Michael Kjörling points out in the comments, this also exposes some of your information in these requests - potentially cookies (if it is the same site / matches the cookie sites / the developer didn't specify secure only), referrers, etc, which will leak some information about what you are doing at the best case and at the worse may allow certain attacks.

This is bad practice on the part of the web developer - all elements should use secure transport.

You could (potentially) improve your own situation using a browser plugin that auto-updates all requests to http to https.


Another solution would be a small all in one firewall appliance like a SonicWALL:
http://www.firewalls.com/firewall/sonicwall-firewall/sonicwall-tz-firewalls/sonicwall-tz-100/sonicwall-sonicwall-tz-100-wireless-n.html
We use a TZ210W at our office and it does everything you mention.  It has a guest wireless for just Internet access.  Using wireless requires a VPN client and username & password to get to the internal LAN. We also use MAC address filtering as an additional control.
We can use both SSL VPN and full client VPN for remote access.
It has built in email alerting.  You can also send the logs to any syslog server.


Would one e breaking PCI compliance in this scenario?

Yes this should be possible. I know of a level one service provider doing basically as you describe. I think it’s a bad idea myself, since you rely on customers to be security conscious, and I would think it opens their PCI scope to SAQ D (which they probably don’t realise). Having said that it’s likely the customers responsibility to be PCI compliant and use PCI compliance service providers. So technically should be fine but feels like you’re playing with fire.

Try Spreedly, they let you use different gateways and also have a vault, not sure about getting the full PAN though.


Scanning DVWA with w3af - Unable to detect SQLi when security on low

You need to configure w3af not to spider the logout link.


How to capture packet using agent in JADE (Java Agent Development Framework)?

I am not familiar with JADE, but at a first glance it doesn't look like it supports packet capture. For that you will need a native binding to a packet capture library. In java, this would be JPCap.

Once you have the packet sniffing working, you need to come up with a set of rules. The preferred method is to create a whitelist; write rules that describe normal traffic, with as little room for change as possible, and then log anything else.


Store Credit Card Information in Password Manager?

The question might come down to: which piece of data has a higher level of risk, your passwords or your credit card info?

Your passwords can be used without you ever knowing about it. Passwords let someone into every aspect of your life with, potentially, every secret bit of information about you that you hold. So, it is possible for someone with your password to completely take over your life without you being aware until it is too late.

Credit card use will be noticed on your next statement, or as soon as your card company posts its use. You also have several types of recourse to dispute charges and have them reversed.

One might suggest that credit cards can be used to set up new cards or other lines of credit, but the same could be said with the information provided by passwords.

Passwords are the higher risk. Credit card info has numerous mitigations in place to protect you.

So, if you trust your password manager with your passwords, there is no increased risk with trusting it with your credit cards. There is always the inherent risk of recording any of this sensitive information, but if you have already accepted that risk for your passwords, then your credit card info does not materially increase your risks.


How to make sure vulnerability management does not lead to reduced or compromised security

Let's take your Node.js example.  You are using a version of with a known vulnerability.  Therefore you have two options:

Stay on the version that you know is vulnerable
Upgrade to a version that may be vulnerable.

The only correct choice is #2.  Is it possible that you are upgrading to a version that also has vulnerabilities?  Absolutely!  In fact that is probably the case, as there is rarely such a thing as bug-free software.

However, the potential presence of unknown vulnerabilities is a red-herring here.  When you know there is a vulnerability (especially when the vulnerability is publicly known), then fixing it is important.  Obviously you don't want to push out a half-baked fix, but staying on a known vulnerable version simply because you are afraid the upgrade may have its own vulnerabilities is definitely a bad idea.


Is html escape enough for mitigating xss in html attribute if value enclosed within double quote

No, that is not possible (note though that the rule is about HTML common attributes and that other attributes like href, src, style, and event handlers are specifically excluded).

The reason that the rule exists is given in the same document you quote:

  Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of the attribute. The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.

The exclusion of non-common attributes is actually relevant in practice. Consider this for example:

<img src="no" onerror="alert('[some user input]')">

An attacker can perform an XSS attack via ');alert('1 if the single quotes are just HTML-encoded. The input would be transformed to &#39;);alert(&#39;1, which would be parsed by the HTML parser of the browser, which then passes it on - in decoded form - to the JavaScript engine.


Can Tor guarantee anonymity when downloading torrents?

Using Tor for torrenting is the way many people got caught.

  So what's the fix? There are two answers here.

  The first answer is "don't run Bittorrent over Tor". We've been saying for years not to run Bittorrent over Tor, because the Tor network can't handle the load

  The second answer is that if you want your Bittorrent client to actually provide privacy when using a proxy, you need to get the application and protocol developers to fix their applications and protocols. Tor can't keep you safe if your applications leak your identity.

  The third attack from their paper is where things get interesting. For
  efficiency, Tor puts multiple application streams over each circuit.

  [...]

  What's the fix? The same two fixes as before: don't run
  Bittorrent over Tor, and/or get your Bittorrent developers to fix
  their applications. But as Tor developers, this attack opens up an
  opportunity for a third fix. Is there a way that we as Tor can reduce
  the damage that users can do to themselves when they use insecure
  applications over Tor? We can't solve the fact that you'll shoot
  yourself in the foot if you use Bittorrent over Tor, but maybe we can
  still save the rest of the leg.

  One approach to addressing this
  problem in Tor's design is to make each user application use a
  separate circuit.

  Another answer is to separate streams by destination port. Then all
  the streams that go to port 80 are on one circuit, and a stream for a
  different destination port goes on another circuit.

  We've had that
  idea lurking in the background for a long time now, but it's actually
  because of Bittorrent that we haven't implemented it: if a BT client
  asks us to make 50 streams to 50 different destination ports, I don't
  want the Tor client to try to make 50 different circuits. That puts
  too much load on the network.

  I guess we could special-case it by
  separating "80" and "not 80", but I'm not sure how effective that
  would be in practice, first since many other ports (IM, SSH, etc)
  would want to be special-cased, and second since firewalls are
  pressuring more and more of the Internet to go over port 80 these
  days.

https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea


Brute force on Hydra with non-ASCII usernames and passwords

This seem linked to language environment:

You could try:

LANG=C LANGUAGE=C hydra -L usernames.txt -P passwords.txt \
  www.xxxxx.com http-post-form \
  "/login.php:log_user=^USER^&log_pass=^PASS^&Enter.x=0&Enter.y=0:ERROR."

or

recode lat1..u8 <usernames.txt >usernames.u8

or if usernames.txt is already UTF-8:

recode u8..lat1 <usernames.txt >usernames.lat1

Then again.

LANG=C LANGUAGE=C hydra -L usernames.u8 ...


Seeking recommendations/warnings for creating a server for malware sample upload and analysis

You are looking at the wrong problem. Handling the file is not an issue. You can save it in the filesystem if you want. You just need to treat is as data. A database blob, a filesystem entry, an in-memory stream. All of those should work.
From Eicar to NotPetya, they are just bytes.
The point where you need to be careful is where programs start processing them. You have a program extracting the file sections? You might worry that if that program was passed a carefully corrupted input file, it didn't cause a buffer overflow that let the attacker run arbitrary code. And so on.
The issue is not "getting it to other programs", it's that whatever those other programs running over the malicious file won't harm the "master" system. That's why you would run those ancillary programs sandboxed in containers, virtual machines, etc.


Why do registers get overwritten upon overflow?

Buffer overflows do not directly modify registers; rather, they are used to overwrite the function return address (the first element in the function's stack frame, 4(%ebp) in x86) and place custom code on the stack which will be executed when the overwritten return address is loaded into EIP/RIP.
In x86 machines, the operations performed by call and ret are of particular interest:

call:

When executing a near call, the processor pushes the value of the EIP register (which contains the offset of the instruction following the CALL instruction) onto the stack (for use later as a return-instruction pointer). The processor then branches to the address in the current code segment specified with the target operand.

ret:

Transfers program control to a return address located on the top of the stack. The address is usually placed on the stack by a CALL instruction, and the return is made to the instruction that follows the CALL instruction.

Taking control of EIP/RIP is accomplished by overwriting the return address call pushed onto the runtime stack with an address that points to the location in memory of code crafted by the attacker. When the ret instruction writes this memory address to EIP/RIP, execution jumps to that address.
You can see this for yourself by stepping through program instructions using a debugger.


Linux authenticating against Active Directory, is one keytab for all Linux machines enough?

The main point of Kerberos is authentication - it allows networked entities to prove their identity.  In order for this to work, each entity needs to have a unique name (in Kerberos jargon, "principal name").

You won't want to share one keytab among all machines, because a keytab contains the secret key of a specific Kerberos principal name.  Sharing a keytab would mean you are sharing that keytab's identity among all machines.  The machines would all use Kerberos to declare that they are the same machinename, and Active Directory will not be able to tell the machines apart.

Consider an analogy: trying to share one keytab among multiple machines is similar to trying to share one Kerberos principal name among multiple users.  You can instruct five people to all use the same username and password... and they can log in... but the system they log into will not realize that there are five separate people.  The system would see multiple connections to one single account, since all the connections are using one single Kerberos principal name.


What is a threat tree in threat modeling?

An attack tree and a threat tree are the same thing.  In a traditional application  threat model, you start with the component that you're building, (be that the entire application, a component or function, a data flow, etc.) and enumerate the  potential threats to that component.

When you're building an attack tree, the development is reversed.  You start with the attacker's end goal, and then enumerate the possible ways you could achieve the end goal, and only then look at the application to find locations where it may be vulnerable to the vectors you've identified.

As Adam Shostack mentioned in his answer, attack trees are generally more suited to more advanced practitioners, and usually as a complement to traditional threat models, not a replacement for them.

Ideologically, attack trees are more a red-team style attacker-centric approach to the problem, which can provide useful additional insight.


After I've plugged my phone into a computer to upload photos, can people see the photos I did not upload even after I unplugged my phone?

Are you using Microsoft Windows?

If so, yes, it's possible, but...

Let's say you connect your iPhone to your computer. If you view the photos on your iPhone in Windows Explorer, then you will have thumbnail remnants for all viewed images. These remnants are stored in C:\Users\username\AppData\Local\Microsoft\Windows\Explorer\ as thumbcache*.db

And yes, this feature is enabled by default. You will have to delete the various thumbcache files. Keep in mind that deleting files doesn't necessarily remove them.

If there are compromising photos of you which were viewed in Explorer, such as IMG_1033.JPG which shows Mark Buffalo in a drag, then you'll want to take extra steps to deleting them to ensure that this secret goes to the grave with you.


Is there a solution that shows a prompt before mounting an USB drive?

Yes, this exists on Ubuntu for example. You can set permissions that require the root password if you are mounting a drive with non-root permissions. I assume similar things exist in Windows and OSX.

However, there may be some confusion in what you refer to as physical attacks. Something like the USB Rubber Ducky: http://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe?variant=353378649 works by acting as both a storage device and a mouse, capable of clicking as if it is a legitimate user. This is similar to how Stuxnet worked, the virus used to shutdown a uranium enrichment facility in Iran. Or there's the drive that's just a huge capacitor that fries hardware: http://gizmodo.com/this-treacherous-220-volt-flash-drive-can-fry-your-comp-1736502260.

While you can definitely improve security by requiring permissions to mount storage devices, I would argue that this isn't enough to prevent against physical attacks in the sense of hardware attacks. It may be useful in stopping employees from moving confidential files around or getting past corporate firewalls by moving malicious programs on flash drives, but it won't protect against usb drives that act like other devices. For that you would have to set permissions for mounting pretty much anything, including any human interface device and not just storage.


Is there any chance of local PC getting infected when you analyse PCAP malware file on a cloud server through putty?

Since you are doing it remotely, it is very unlikely to affect your local system unless you either expose your local system's services via tunneling or there is a previously unknown vulnerability in the software you are using (Putty). The malware would also need to be specifically designed for such a particular attack vector, which is also rather unlikely.


How are SCrypt's memory-hard requirements substituted with more CPU?

SCrypt's memory usage comes from its use of a long list of psuedo-random numbers.  Since this list is pseudo-random, there are two ways of dealing with it:

Pre-compute the entire list and store it in memory.  Since each element is expected to be accessed many times, this reduces the CPU cost but increases the memory cost.
Compute each list element on an as-needed basis.  This has many times the CPU cost of pre-computation, but memory use is reduced to only the list element that is actually being used at the current step in the process.

It may be possible to do a hybrid algorithm where part of the list is pre-computed and the rest is computed on an as-needed basis, but most implementations will go for one extreme or the other.

The goal is to limit the ability of GPUs to compute many hashes in parallel.  Since the typical GPU has only a few megabytes of RAM per core, an attacker needs to either use an efficient algorithm on a few cores, or use all the cores but a highly inefficient algorithm.


How can the connection of a rogue VPN router be countermeasured with a sniffer?

The best way to mitigate this attack is likely to have good knowledge of the systems on your internal network and control access as much as possible.

One common way to address this is to make use of things like 802.1x authentication for endpoints, such that connecting a rogue system to the network will not provide an IP address and the connectivity that this attack would require.

You could also introduce authentication for web traffic on a proxy server and block all unauthenticated attempts to get access.

Also you could do monitoring of your Internet traffic to look for unusual traffic patterns.  A node maintaining a VPN would be sending traffic 24/7 so should show up as anomalous if it was placed in a location that generally only had users present from 9-5 say.

As with all things security, there is no one measure that would prevent this but you can make it harder for attackers to execute, and give yourself more opportunities to detect it.


Is it nescecary to wipe and reset the MBR when laptop changes owners even if full disk encryption is used?

The Center for Magnetic Recording Research at the University of California, San Diego has an interesting document on Data Sanitization in the form of a tutorial on secure wiping of storage media. They explain that securely destroying the decryption keys securely renders the data on the disk indecipherable and thus inaccessible (especially with strong encryption such as AES-128 or AES-256 which is used by Symantec's PGP WDE by default).

A research centre specialized in these mattesr and the company that made the product. It doesn't get more authoritative than that. Good luck with your boss.


Authenticated user moving for a different service

This is very like a single-sign-on service, except usually there you don't control all of the services yourself (instead, one of them is controlled by the SSO provider, such as Facebook or Google). You can look at OAuth2 for some ideas of how SSO is most commonly implemented, but it's honestly overkill for a scenario where you control both services.

Assuming for the moment that you control both services and calls between them are sufficiently cheap, one simple solution is to have one of them be the source of truth on identity, so service2 simply checks service1 for confirmation of who the user is and what they can do (what their secret data is, how many credits they have, etc.), without storing any of that information itself. The problem then is linking the user's session across both services.

You can use the URL approach:

service1 generates a single-use secure random token and passes it to service2 in the URL
service2 sends that token to service1 through a direct channel
service1 replies with a session identifier for the user's session and also any additional data service2 will definitely want
service2 sets the session identifier from service1 as its own session identifier on the client (probably in a secure cookie) and optionally stores the required data in its own session state for that session

Alternatively, you can use CORS (Cross-Origin Resource Sharing), which is a way for a web browser to break the same-origin policy in a controlled way between sites that trust each other (and are possibly controlled by the same entity). CORS lets you make XMLHttpRequest or Fetch calls across origins and see the responses. An example might look like this:

service2 gets a request from a new user who doesn't have a session, or a user whose session had expired
service2 replies with a page containing script that makes a CORS request, with authentication, to service1
Assuming the user is signed into service1, service1 accepts the CORS request and responds with a single-use securely random token
The client-side script sends this token down to service2
service2 sends this token to service1 via a direct back-channel
service1 verifies the token and sends a session identifier to service2, etc.

This scheme is the same as passing the token in the URL, with two exceptions:

The token is never sent in the URL, and therefore much less likely to wind up somewhere it shouldn't like a server log or browser history.
The user can go directly to a service2 URL without clicking through a special link from service1, so long as they have an active session on service1.

Note that the session token itself is never sent in a response body (that the client sees). You could simplify this scheme if you did - then the client script would set the session ID in a cookie for service2, eliminating a client-service2 roundtrip and a service2-service1 roundtrip - but then an attacker with an XSS could steal the session token (as opposed to "merely" having complete remote control over the compromised session for as long as the user has the page loaded).


How much can an attacker do/obtain in PHP with the execution of one function?

Using build-in PHP Functions

With just these two lines, I think that it's unlikely that you can do much more than phpinfo, because it doesn't seem possible to pass arguments to the function, which severely reduces your options.

There seems to be some confusion in the comments and other answer, so to make it clear: $_GET values are treated as strings, not as PHP code. This means that none of the provided options  -  anonymous functions, executing arbitrary code, using "echo hello"->system, using exec('rm -r /') - will work.

You can't even leak other information besides phpinfo - eg get_current_user - , as the result of the call is not echoed.

There may be some obscure corner cases that may be considered vulnerabilities. For example, with certain settings SSRF/DOS via ingres_connect may be possible (although far fetched).

Using the surrounding code

Apart from the phpinfo leak, that would mean that you need to exploit the surrounding code. Some possibilities might be:

DOS via a very expensive function call
Authentication bypass
Filter bypass
...

Basically, the code gives you control over the control-flow of the application, and that's what you need to exploit.

This is also not limited to just included functions. Since version 5.4.0, you can also call methods of any included class:

fcall[]=MyClass&fcall[]=myFunction

But again, you cannot create new objects via this code:

$_GET['fcall'] = array(new MyClass, "myFunction");
$fcall = $_GET['fcall'];
$fcall();

The problem is the same as before: $_GET is treated as string, making it non-working as soon as the value is actually passed to the server instead of hardcoded.


Does Wordpress REST API with CORS enabled represent a security risk?

CORS is a commonly misunderstood mechanism and even some security scanners get it wrong.  For example some will flag Access-Control-Allow-Origin: * as a serious concern, without realising that the browser won't send credentials (e.g. cookies) with the request (you can't combine that wildcard value with Access-Control-Allow-Credentials: true).

That's the most common case, hard to say if that's what's been reported in your case without the details of your CORS policy.

The main risk I can think of, of having a REST API with CORS would be if an untrusted origin was listed in ACAO, you had ACAC: true set and a user visited the untrusted origin whilst authenticated to the site and a request was passed with their cookie(s) to the site allowing for protected content to be retrieved, as you can see a fairly convoluted setup.

If you want more information on CORS, I'd recommend reading this and this.  Also worth noting that Wordpress's REST API may have some security concerns for example, retrieval of valid usernames without authentication


Control flow integrity and data flow integrity

Does it make sense to have DFI and CFI?

No.

  Does DFI imply CFI?

Yes, because hijacking the control flow means modifying a control-data and DFI ensures the integrity of data whether it is used for control or not.

  Can I still use exploits that alter the control flow graph (CFG) if I have only DFI?

No, it will be detected.

DFI enforces a policy on the data-flow observed at runtime. It ensures that a program must follow a data-flow graph generated via a static analysis at compile time. An instrumentation pass on the program adds checks before each read instruction to ensure that they do not read a corrupted data.

The static analysis uses a reaching definition analysis. It is a data-flow analysis that gives us for each read instruction reading a variable, a set of instructions that could have last defined this variable.

For each read instruction the analysis is performed, and each write instruction that defines a variable is assigned an unique identifier.

Then, an instrumentation pass adds checks before each write instruction to  update a table mapping an address being written to and the last identifier  having written a value at that address.

In addition, the instrumentation adds checks before each read instruction. It fetches the identifier mapped with the address it is reading the value from, and it ensures that the identifier is in the set of reaching definitions found thanks to the static analysis.

For instance, if an attacker manages to corrupt the return address on the stack, the write instruction used to corrupt it updated the table with its identifier. Hence, the instrumentation just before the ret instruction will notice the corruption, because the last identifier used to modify the return address is not in the set of allowed identifiers.

That's why DFI prevents both non-control data attacks and control-data attacks. It also explains why it does not make sense to use both, because it would be redundant.


Can a student ID containing an NFC chip be cloned?

Many NFC enabled smartphones can write to these cards with an app like MifareClassicTool. However I've found several phones seem to be able to do it when in reality trying to write to Sector-0 bricks the card. It may be worth testing one or two cards and if it doesn't work buy a dedicated USB writer.

First of all a huge number of Mifare Classic Systems only use the ID on the card. This is stored in Sector-0 which is theoretically read only. Of course plenty of online sources will happily sell you cards where this is writable. Writing to the cards themselves is trivial.

The encryption on the cards has also been broken and again can be trivially cracked on a smartphone, as seen on Wikipedia: Security of MIFARE Classic, MIFARE DESFire and MIFARE Ultralight. My university used the same cards. As did an Oracle facility I used to work at…


How safe is WSIT username authentication with symmetric key?

Looking at the linked article this looks very similar to standard web authentication in that the server has a certicate, the client uses username/password auth. to authenticate and then a shared key is used to encrypt communications.

So on that basis the answer to your question is similar to what it would be for standard web auth.  Assuming that the client checks the validity of the servers certificate at runtime and that it posesses the means to check for things like certificate revocation it is reasonably likely to be protected against a MITM attack (unless the server certificate is compromised).

Data sniffing would be protected against the encryption of the data stream which appears from the docs to be done be symmetric encryption.


Can I use a private key as a public key and vice versa?

But say I want the server to encrypt data using the private key and decrypt it using the public key, as a way of distributing data that can be verified to have come from the right server.

You can do this - this is, at a very simplistic level, how RSA signing works (note, simplistic - there is a bit more to it).

  Rather than modify the code to allow this, can I simply publish the private key and keep the public key secret? Does this affect the security of the system?

You don't need to publish the private key at all - RSA is a trapdoor permutation which means:

If you encrypt with a public key, you can decrypt with the private key.
If you encrypt with a private key, you can decrypt with a public key.

Thus, RSA supports doing both signing and encryption relying on the end user having only the public key.

In your case, if the client wishes to verify data came from the server, you apply the second case of RSA and decrypt the signature data using the public key you already have.

Furthermore, because it is a permutation, you shouldn't need to modify your code at all. Both keys should work using the same function. I would expect any decent crypto library would have APIs for verifying signatures according to the varying standards that exist - one of these would probably be a good bet.

RSA Labs provide a nice explanation of this.

If you want to extend this between servers, or verify client communication - generate keys for each entity and swap the public ones. The process can then be used at both ends.

Theoretically speaking, e and d are interchangeable (which is why RSA works)(one must be designated secret and kept secret) but p and q must always be kept secret as these allow you to derive d from e and vice versa. However, you need to be extremely careful in your understanding of the private key - does your software store p/q in the private key? If so, you can't publish it as is. Also, when I say interchangeable - once you publish one of that pair (e or d along with your modulus n) you must guard the other with your life. Practically speaking as Graeme linked to in the comments e is often chosed as a small/fixed value. My comment on e/d being interchangeable clearly does not apply when e is easily determined. Doing this sort of thing therefore has the potential for confusion and mis-implementation. Use a third-party library/don't start publishing private keys.


How can I recognize and find file(s) dropped by malware?

There are generally three ways:

Sandboxing (which you said you don't want to do)
Tools like Process Monitor can display all file and registry activity on the system, but this approach is limited - rootkits would hide the changes, or the malware might notice procmon and change its behaviour.
Snapshot comparison. Take a snapshot of the filesystem, then run the malware, then take another snapshot and compare them. You'll be able to see what files were created and changed.


How to run OWASP ZAP automatically using command line operations (i.e. Jenkins)

I ran into a similar issue while trying it. Not sure if you found a way to set the ZAP home path for the zapr wrapper. This worked for me:

zapr --summary --debug --zap-path $/usr/share/zaproxy/zap.sh http://localhost:3000


No. Cloudflare is a reverse proxy. When a site uses Cloudflare, the client (browser) never connects to the origin server. They can even help you hide the origin server, so an attacker cannot attack it directly.

The client connects to a server in one of ~200 Points Of Presence they have around the world (server farms), the request is processed by the server there (rate limiting, TLS, WAF, page rules, cache, arbitrary JS code, etc.) and if needed, the Cloudflare server connects to the origin server, performs a request, gets a response, transforms the response, caches it locally and serves it to the waiting client. Cloudflare is Man-in-The-Middle-As-A-Service. You give them DNS control, they generate a TLS certificate for your domain and front the domain. It's possible that your origin server sees a tiny fraction of the number of requests served, and this lets a tiny origin server to handle a lot of legitimate traffic, stand up to DDoS attacks, etc.

There are a lot of things you can configure, but that is the general idea. Cloudflare can also do just authoritative DNS server, without being a proxy. They can let you keep your TLS key, for compliance reasons. They are good at explaining how their products work and publishing many details on their blog, so I suggest you read their developer docs (not the marketing material for non technical people).

You can also contact their customer support.


How facebook knows my new password is too similar to my old password?

We do not know how exactly Facebook manages user passwords, however, we can imagine this scenario:

A new user logs into his Facebook account using the password: Password1. It is likely that, immediately, Facebook generates similar passwords such as: Passw0rd1. pAssword2, Passmord1 ...etc.

Facebook then stores their respective hashes (which are different, of course) so that if a user user types his password (after reset), the hash of the new password is compared to all these stored hashes: Facebook can tell you then if your new password is similar to the previous one or not.

EDIT:

Following @Philipp comment saying  Facebook does not hash passwords, I want to share this information that I quoted from the official Facebook documentation (Keeping Passwords Secure):

  We hash each password using our internal password hashing algorithm
  and the unique salt for that person. Since Facebook stores passwords
  securely as hashes, we can't simply compare a password directly to the
  database. We need to hash it first and compare the hashes.


Can somebody explain why the IP address 192.168.1.1 is apparently "special" and not following the CORS rules?

They're not being treated differently.

As explained in the answers to the original question, if a malicious site had a script that requested //127.0.0.1/private.txt, they would not be able to read that file.  However, what was glossed over is that your browser would still make the request to your local web server.

The only protection that Cross-Origin Resource Sharing (CORS) provides, in the context that you're asking, is the malicious script will not be able to read the data in your file.

In the answers on the original question, we are warned that even though the malicious site could not get the data from that file, they can still cause side effects.  The example that we are given, where a router's admin panel was exploited in order to give external access, was simply an arbitrary example where someone can cause damage within the secure parts of a home network, even if they can not get data from that.

In the example, if (instead of simply trying to read sensitive information) the malicious site caused you to load //127.0.0.1/deletePrivate_txt.php, your browser will make that request to your local web server.  They won't be able to read the results of that request, but the request will still happen, and whatever side-effects that this script has (such as deleting every diary entry since 1958) will happen as well.

CORS protects sites from reading sensitive information, regardless of the IP address of the web server.  However, CORS does not (and is not designed to) protect against Cross-Site Request Forgery (CSRF).


I found a virus on my USB stick. Now what?

Step 1 - Nuke your USB drive. Format the thing.

Step 2 - Nuke all the computers that you have used the USB drive with in the period which you suspect the drive has been infected.

Step 3 - Change your passwords.

Step 4 - Submit the malware to something like VirusTotal. It will ensure that most of the major antivirus vendors pick up on it.

Step 5 - Harden all Windows computers you work with by following guidelines posted by NIST, including disabling all autorun features for all types of media.


Storing passwords of third party services (web app)

The best way to do this would be through oAuth.  Check to the documentation on the websites to see if that is a viable option.  If it is not, it is definitely not recommended to store user credentials in any form on a webserver, a browser, or anything else.  Normally when you validate a login you are validating that the hash (plus a salt) of the password matches what is in the database.  The password is never actually stored in the database not even in a encrypted form.  In this scenario there is no way for an attacker to know what the password for the user is even if they are able to compromise the database (short of a brute force attack).


Assuming a good hash system, if 2 hashes has about 50% of their bits the same, what is the likelihood that the corresponding plaintext is the same?

Looks like a trick question.

With a perfect (cryptographic) hash then there should be no correlation between the input and output of the hash, therefore the similarity of the hash outputs should bear no relation to the similarity of the 2 inputs.

Indeed, if you pick 2 random hash outputs then, on overage 50% of the bits will be the same. If you pick any 2 random peices of data, then on average half the bits will be the same.

If you apply the same hash function to the same data it should always produce the same result. There's only a very low probability of 2 different messages picked at random resulting in the same hash (a collision). The likelihood of this occurring for a perfect hash is dependant on the length of the hash (with a 1 bit hash, the probability is 50%, 2 bits, 25% etc).

The similaritiy of the output has nothnig to do with the similarity of the input.


Why delete user accounts, when no longer needed - business

From my experience, there are 3 key concerns when an employee leaves an organisation:

The risk of remoting in (As you said)
Other employees (eg: admins) could abuse use the ex employees credentials knowing they would be difficult to track. Alternatively, disgruntled ex-employees could give their creds to an internal staff member and collude to leak out info.
Data that the ex-employee leaves behind needs to be archived in case the organisation needs it (eg: important files/emails, etc). But this needs to be done securely as there could be personal/private employee info that is left behind which should not be accessible by other staff

These 3 reasons are the main reasons I find why employee accounts need to be deleted immediately on exit. It is also common practice for organisations to leave accounts around for while for "Housekeeping" purposes, but this practice again is very questionable.

Hope this helps

R


Why SPAM mails have UK Contact Addresses and Emails?

This data is fake data usually. They are using UK to make it look more legitimate depending on the target address most of the times.

You can spoof anything in the email except for the sending IP address and DKIM/SPF records which the companies you have in your list are not using.


Wiping a hard drive before reinstallation

The good part here is that you want to completely install a new OS. You don't need Windows to work or not be infected. In fact, you could fill the disk with random data prior to the Linux install in order to ensure nothing is left.
You mention that you are concerned about something there latching into the new OS. A virus installed on Windows affecting a clean Linux install on the same hardware would be extremely rare. Even for a clean Windows install it would be very strange to be affected, it is possible to store blobs in the BIOS that would then be loaded by Windows on install, or there might be a firmware virus installed. These are not things that would be even remotely likely to happen (probably not likely even if a foreign government wanted to spy on you), nor things that might be checked easily (or at all). Installing Cinnamon configured to wipe the existing contents would be enough to make that machine start from a clean state (other than getting new hardware).


How can I defend against malicious GET requests?

These requests do not look really malicious. At least based on your description they don't cause any harm, i.e. no unwanted code execution, SQL injection or similar attacks. They only need some resources to process. What you see is what every operator of a web server can see in the log files: lots of requests which don't match anything existing on the server because somebody is scanning the internet and looking for vulnerable systems. Additionally these  requests can also be caused by changes to your site where formerly valid URL's are now invalid but robots still remember the old URL's and check these for updates.

If these requests bother you then you can either change your application to ignore such requests (and not log them as errors) or filter these requests by a server/reverse proxy in front of your application.

While the suggested web application firewall (WAF) can filter such requests I would consider it overkill to install one just to filter these harmless requests. But properly used (i.e. adapted to the application instead of just installed and forgotten like often the case) it can be a useful layer of protection. And while the suggested fail2ban can help too it is only useful if these requests originate only from a few single IP addresses, which is often not the case. Moreover a reliance on fail2ban can lock out valid users since invalid links to your site can be included in mails or other websites and thus the originating IP address of the request is not the attacker but an innocent user which got tricked in visiting this link. But fail2ban only sees the originating IP and the error message and then locks out the innocent user.

What you should do is make sure that your application is not vulnerable and OWASP is a good resource to learn about securing web applications. If your application is secure than it has no problem dealing with these kind of requests. But to limit resource usage from invalid requests you should make sure that these requests get detected and rejected as early as possible in your application, i.e. it would be bad if invalid requests would also trigger costly queries against a database.


How does Firefox encrypt passwords without selecting Master Password?

When the profile is initialized, a blank password (an empty string) is used. You can find the code for this in toolkit/components/passwordmgr/crypto-SDR.js on line 64:

if (token.needsUserInit) {
  this.log("Initializing key3.db with default blank password.");
  token.initPassword("");
}

Additionally, based on the import method in toolkit/components/passwordmgr/LoginImport.jsm on line 68, the encrypted passwords are imported into logins.json from key3.db without modification. Therefore, they will be using the same default password.


Best practices: Use of a single private key as a person, or multiple to identify self across domains?

The problem with this approach is that the same identity is used by every destination, so sites can swap notes to see where you've been and draw correlations that you may not want to expose.

There are several ways to solve this issue, such as the one used in the FIDO U2F security key. In this case, the device contains a symmetric key (not an asymmetric key pair) and the necessary crypto hardware such that the secret key never needs to leave the device.

On site enrollment, the device creates a new public/private key pair and sends the public key to the server along with a "key ID" for that key. On authentication, the site sends to the browser the "key ID" for that user and expects the response to be signed with the corresponding public key.

But instead of storing the private key corresponding to each key ID, the ID is itself the private key encrypted with the device's secret symmetric key.

There are additional features to the protocol to make phishing impossible, but those are beyond the scope of this answer.

Note that this is only safe because the secret never leaves the hardware. The same principle is true for any hardware security token; it's the fundamental difference between a true security key and something like a thumb drive; a storage device can be copied. This is at odds with human-implanted keys because the hardware necessary to do actual crypto calculations while being powered by NFC requires too much area to comfortably fit under the skin.

Using a protocol like this one gives you the added advantage that it's already supported by other peoples' sites, so all you have to worry about is your local implementation. But it's not so good for SSH keys and such. If you're going to use it as an SSH key, you've got to get it to somehow communicate with your key agent (which probably means writing a new key agent).


Why must I use numbers when displaying SSHFP DNS records?

The presentation format is part of established DNS terminology, as explained in RFC 8499, 5:

Master file:  "Master files are text files that contain RRs in text
form.  Since the contents of a zone can be expressed in the form
of a list of RRs a master file is most often used to define a
zone, though it can be used to list a cache's contents."  (Quoted
from [RFC1035], Section 5) Master files are sometimes called "zone
files".
Presentation format:  The text format used in master files.  This
format is shown but not formally defined in [RFC1034] or
[RFC1035].  The term "presentation format" first appears in
[RFC4034].

It is in the master files or zones where you should use this presentation format. GUI clients and configuration interfaces are free to present the data however they like, and they do.


What is the meaning of "Key Deletion" operation?

I hate saying this but, depends on the context.

If you have a lot of documents depending on one key, when a key expire you can do one of the following:

Recypher your documents, so you can truly delete your old key.
Keep old documents cyphered with the old keys, so you just mark your key as deleted and reuse it when you have to obtain those documents.

About "re-creating" the key, it will be very difficult, if not impossible, to regenerate the very same key again if you use standar creation mechanisms, so don't rely on that.

When truly deleting a key, the best practice is purging it (shred it) if you have an old HD, if you have a new HD either you just delete it or on SSD you are screwed or destroy it and buy a new one (you will have to make a decision depending on the system and its security requisites).


Mutual SSL for clients of SaaS cloud service

Given that both client and server are fully within your control I consider it the best (and maybe also easiest) thing to rely only on self-issued certificates so that you don't need to trust some external CA which is outside of your control.

If you have only a few communication peers it might be easy to go with self-signed certificates and exchange these when needed. Note that you could simply pin to the specific certificate or public key in this case and ignore any expiration, revocation etc - since everything is in your direct control anyway.

With more communication peers it is probably better to create your own PKI structure, i.e. have your own root CA which issues certificates for both clients and servers and which can also renew and revoke certificates. Once this PKI is setup the management of the communication peers is simplified since they only need to trust this specific CA (and only this CA). A simple PKI structure could be created with openssl already but there are also commercial products which might provide better usability and also scale better.

Given that you have full control over both clients and server it is actually possible to start simple and cheap (self-signed certificates), grow slowly but remain cheap (openssl based CA) and then move to an (not so cheap) enterprise CA when lots of clients are involved.


VirtualBox + VPN with Win10 Host - how secure is it?

Security and Privacy is a relative thing. The configuration you describe is pretty solid and is likely sufficient for most situations.

However there are less likely possibilities that can effectively defeat the described configuration. You mentioned one already, “Key Loggers”. Another is a host level process that can access the running unencrypted virtual system once you start it.

It’s unlikely that a legitimate company will deploy the kind of extreme level surveillance necessary to thwart your approach, but it’s technically possible. It’s far more likely that admins will note your encrypted virtual disks and ask about it, as well as your use of a VPN. If a response of, “Personal Stuff” would be acceptable, then your protections are likely sufficient.

If you are concerned about the less likely more extreme monitoring potential, then an external bootable OS that completely bypasses all corporate software is necessary.


Simple-to-implement ad-hoc password validation scheme

The problem with the method that you have suggested is that it is basically a partial-key exposure of RSA. You are exposing some bits of a factor of a semiprime. Dan Boneh's survey on RSA attacks lists a theorem from Coppersmith that states that if the n/4 least significant or most significant bits of a factor of N are known, then N can be factored efficiently. Since you want to leak way more than n/4, I think your method would be susceptible to that attack.

The good news is, Boneh gives some insight into something that might work:

  It is interesting that discrete log-based cryptosystems, such as the ElGamal public key system, do not seem susceptible to partial key exposure. Indeed, if g^x mod p and a constant fraction of the bits of x are given, there is no known polynomial-time algorithm to compute the rest of x.

So, you could pick some random x, a large prime (1024 bits) p, and a generator g (in practice I'd use some standard NIST values for P and g). Compute g^x mod p, store that in your software. Store some number of bits of x in your program. The user must supply the remaining bits of x. Call their bits plus the stored bits x'. You compute g^x' mod p and see if that matches with what you had stored.

I believe that the statement from Boneh has not changed since it was published. That maybe something you want to ask on Crypto.SE, along with recommendations of how many bits should be left out of the source code.


don't know about the smartphone case, but with Wireshark, as long as you own the key you can.

Here you have a video doing all the walkthrough and here a Wireshark wiki post about it. Basically you need to go to the preferences of the SSL protocol and put the key file.


Nessus web client: Error 401 invalid credentials

First check you are entering the username which exists(presuming you're using linux)

ls /opt/nessus/var/nessus/users/

if user exists, reset the password and try again with new password.

In the command-line, type:

On Windows :
C:\Program Files\Tenable\Nessus\nessus-chpasswd.exe <username>
On Linux:
sudo /opt/nessus/sbin/nessus-chpasswd <username>
On Mac:
sudo /Library/Nessus/run/sbin/nessus-chpasswd

Note: Root/Admin Privileges required.

EDITED JUNE 7, 2020

This is no longer accurate. Per tenable.com...

On Windows:
c:\Program Files\Tenable\Nessus\nessuscli.exe chpasswd <username>
On Linux:
/opt/nessus/sbin/nessuscli chpasswd <username>
No instructions are given for Mac, but assuming the same approach:
/Library/Nessus/run/sbin/nessuscli chpasswd <username>


Why were Meltdown and Spectre disclosed at the same time?

*Update: This article seems to cover everything.

The attack papers share many of the same authors and use similar but previously unknown attack vectors.

Both exploits resulted from the same (or at least inter-related) bodies of research. Both were initially reported on the same date (2017-02-01) - CVE-2017-5754, CVE-2017-5753, CVE-2017-5715

So assuming you view both of an equivalent seriousness it makes sense the embargo / disclosure period were the same for each. Seeing as both were reported on the same day you would expect both to be publicly released at the same time.

Meanwhile from the authors perspective were one to be released earlier it would have clearly got the majority of the press attention. It seems like a fairer approach for both parties to be equally recognised.


You can't use certificate-based authentication to "hide" a machine in the same way that a VPN hides a machine -- which is what the PCI Standard intends in section 1.3 in v2.0 of the PCI-DSS Standards.

1.3. Prohibit direct public access between the Internet and any
system component in the cardholder data environment.

Each of the components of 1.3 refer to avoiding direct contact with the system component.  Direct contact means that your machine has a publically accessible IP and can be communicated with directly.  A certificate-based authentication system does not preclude section 1.3 because it offers no protection against OS/network-stack level (or similar) vulnerabilities which could be used to penetrate and avoid the authentication system.

The sub-requirements go on to describe specific methods that must be in place to prevent public access -- intervening network-level protections such as firewalls, VPNs, etc.

If you have not already read it, please read "Understanding the Intent of the Requirements" as an interpretive guide.  Section 1.3's interpretation basically says exactly what I said above:

A firewall's intent is to manage and control all connections between public systems
and internal systems (especially those that store, process or transmit cardholder
data). If direct access is allowed between public systems and the CDE, the
protections offered by the firewall are bypassed, and system components storing
cardholder data may be exposed to compromise.

Ultimately, this means that as long as your manual system is protected with an intervening security firewall or other masking solution (eg. VPN) that also conforms to the requirements laid out in (all of) section 1, then you should be fine.  You wouldn't even need to use certificate-based solutions as long as all of the other identification & authentication pieces are securely implemented as per the PCI standard.


How to securely share sensitive info (such as API keys) with freelancers?

The exact procedure you follow will necessarily change depending on the service you use. However, there are some common precautions you can take:

Switch to services that have robust, featureful key systems. Strictly from a security point of view, if it doesn't support all of the rest of the items in this list, you should look for alternatives. (Obviously, business needs and your abilities also need to be taken into account -- but only you can do that)
Follow the principle of least privilege -- when generating keys for the freelancer, ensure they have the minimum amount of permission required for them to do their job.
Make sure keys can be revoked quickly and automatically, with no human intervention required on the service's side. This allows you to react to bad actors. In this case, if you can easily revoke the freelancer's keys, they no longer have anything to hold over your head, just a meaningless string of bits.
Give the freelancer unique keys, so that you don't need to rotate all your keys just to revoke the one person's access.
Always have a second access method which can't be revoked by the freelancer for yourself/your business partner, so that they can't steal your account and hold that as blackmail.
Give the freelancer a test area to develop in, rather than having them work directly on the production server. Not only does this isolate their access to prevent damage, but it also prevents stupid mistakes from (however briefly) taking down your entire site -- if changes can be tested and demoed in a test environment, you'll have more confidence that they work before they're deployed to your customers.

Less directly, you should also keep regular offsite backups that freelancers don't get access to. That way, even if something is compromised, you can roll back to a non-compromised state easily.

Ultimately, you're necessarily giving someone in-depth access to large parts of your project. There's no way to do that absolutely safely, and what measures you can take depend on what the keys are used for.


Does OAuth 2 increase the risk for clients to expose their "client_secret"

Let’s go over the “authorization code” flow and along the way I’ll clarify and address your points.

The OAuth2.0 standard has a few grant types but the most common I’ll go over is Authorization code flow.

Let’s say we have a webapp that wants access to a resource (say your google calendar). Our webapp requests access to your Google account by opening the browser to a google.com authorization page. You click allow which sends a redirect to your app in the browser URL, passing an authorization code.

The backend of our application takes that authorization code and along with the client_secret, and other params, requests an access token from the authorization server. This happens once!

Once our webapp receives the access token, our application can make api requests to the resource server as long as it’s valid.

To address your issue. No, it is more secure, because the client_secret is only sent over the network once, not every time. Once we have the access token, that is the only sensitive information that is being sent over the network. It also has a finite lifespan. This is why it’s more secure. The client_secret is sent by the confidential backend server and is not exposed to the browser further limiting risk of exposure.


Why are ciphers using DSS being offered when using DH+AES:!DSS?

From the documentation of ciphers:

  aDSS, DSS
  cipher suites using DSS authentication, i.e. the certificates carry DSS keys.

To have a closer look at the ciphers you wonder about:

$ openssl ciphers -V 'DH+AES:!DSS:!aDSS:!aNULL' | grep DSS
      0x00,0xA5 - DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(256) Mac=AEAD
      0x00,0x68 - DH-DSS-AES256-SHA256     TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AES(256)    Mac=SHA256
      0x00,0x36 - DH-DSS-AES256-SHA        SSLv3 Kx=DH/DSS     Au=DH   Enc=AES(256)    Mac=SHA1
      0x00,0xA4 - DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(128) Mac=AEAD
      0x00,0x3E - DH-DSS-AES128-SHA256     TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AES(128)    Mac=SHA256
      0x00,0x30 - DH-DSS-AES128-SHA        SSLv3 Kx=DH/DSS     Au=DH   Enc=AES(128)    Mac=SHA1

Have a closer look at the 'Au=...' column which describes the authentication used. Clearly all of these are using Au=DH and not Au=DSS, i.e. they are not using DSS for authentication and are thus not covered by the DSS string in the ciphers setting. All of these are using DSS only within the key exchange as Kx=DH/DSS shows.

Au=DH essentially means that the certificate contains a static Diffie Hellman key as subject public key info which is used for authentication and with Kx=DH/DSS also as part of the key exchange.


Is it safe to keep a hardcoded oAuth token on an app built solely for personal use?

"Safe" is a relative term, and not very helpful in a security context. Whether or not it is "safe" depends on what it protects and how you use it. If the app controls the US nuclear arsenal and you frequently leave your phone unlocked on the counter of public bathrooms while visiting Iran, I would say it is terribly unsafe. If only accesses your own personal GitHub (which does not contain state/trade secrets or nuclear launch codes), then I would say it is reasonable.

Hard coding credentials in an app you don't share is as secure as your phone or personal computer is. From a phone-security perspective, someone who has full access to your phone will probably be able to retrieve the key just as easily out of the phones memory whether it came from an oAuth flow or source code.

On the plus side, the fact that it is hard coded means no one can attack the oAuth flow - one less security risk. However it is stored in plain text on your laptop (in the source code presumably) - one more security risk. Again, which is "better" depends on your circumstances and expected threats, but for a typical person that isn't being directly targeted by skilled hackers, it probably doesn't make much of a difference.


What is the method used in the New York Times attack?

The article you linked to gives as much information as is publicly known. So I'll just quote from there:

  Investigators still do not know how hackers initially broke into The Times’s systems. They suspect the hackers used a so-called spear-phishing attack, in which they send e-mails to employees that contain malicious links or attachments. All it takes is one click on the e-mail by an employee for hackers to install “remote access tools” — or RATs.

And also:

  The malware was identified by computer security experts as a specific strain associated with computer attacks originating in China.

Which means that this isn't software you're going to find on metasploit. It's something custom that they built.

  They set up at least three back doors into users’ machines that they used as a digital base camp. From there they snooped around The Times’s systems for at least two weeks before they identified the domain controller that contains user names and hashed, or scrambled, passwords for every Times employee.

So, 3 employees workstations compromised with RATs (probably via email spear phishing) leveraged to gain access to the domain controller.

  While hashes make hackers’ break-ins more difficult, hashed passwords can easily be cracked using so-called rainbow tables — readily available databases of hash values for nearly every alphanumeric character combination, up to a certain length.

Active Directory is known to use unsalted hashes for password storage. There are several methods AD uses for hashing passwords, none of them very secure ... except perhaps as compared to the previous ways Microsoft hashed passwords. Their security is based primarily on the assumption that Windows access controls will prevent the attacker from retrieving the hashes. But if the attacker uses a targeted phishing attack to compromise the workstation of someone who has the necessary access, then AD won't put up much further resistance, and the attacker can then learn everyone's password.

After cracking the passwords stored in AD, the attackers then have the necessary credentials to do whatever they want to do. In this case, read email.


If I use my own cloud server as a VPN can my internet traffic be tracked?

From the perspective of the Bit Torrent swarm, your virtual server will appear as a client and the swarm will learn its IP address. Virtual servers rented from IaaS providers usually have static IP addresses, so the provider knows which IP address belongs to which one of their customers.

When someone wants to press legal actions for copyright violation, they will notice that the IP belongs to a block of IP addresses registred by the IaaS provider, and press charges on them first. Their complaint will include the IP address of your server. The provider will then look up who pays for the server with that IP address and forward the complaint to them.

When the provider does not cooperate, they could be made liable for the copyright violation themselves. So you likely can not rely on your IaaS provider to protect your anonymity in case of legal problems.


Generate Passphrase from the data & encrypted data

This is called a "known plaintext attack" (not to be confused with a chosen plaintext attack).

There is a known plaintext attack called XSL which some people believe could work on AES, but it is important to point out that even if it did work, it would still take hundreds of trillions of years to break the encryption. (That counts as working in cryptographic terms because it's less than the thousands of trillions of years that brute force would take.)


How can I prevent email spoofing from my domain?

You could go beyond SPF - add DKIM to the mix, and you can use DMARC, which will not only prevent spoofed emails, but also allows you to receive reports of them.

SPF basically lets you list your legitimate servers, and DKIM signs emails to attest to their validity.
DMARC then allows you to define how receivers should deal with email that fails SPF or DKIM tests, and how they can send you reports.


Nmap giving different result between Mac OS scan and Linux (Kali) scan

This can be because of many reasons. Such as the following:

Network Layout
Antivirus Software
IDS/IPS
Intermediate Network Devices
The version of your Nmap's
..etc

In your case, it seems like you are using your MAC OS as the host. While Kali Linux is a VM with the MAC host. If you have an Anti Virus software or Strict Firewall rules enabled, they could be dropping the requests begin generated by your KALI VM-nmap scan. Which is in turn giving you different results on the different hosts.

In Order to verify this hypothesis, you can try to boot up Kali as a host and try scanning the "said" machine again with the same versions of Nmap.


Given the following yaSSL ciphers, how do I know what's being used?

Generally, the output of yaSSL, sslscan etc. are going to be in the following format:

<key_exchange_mechanism>-<authentication_mechanism>-<symmetric_algorithm-key_size>-<hashing_algorithm>

So in your example, DHE-RSA-AES128-RMD is Diffie-Hellman key exchange using RSA for authentication, with AES128 for symmetric encryption, and RMD for hashing. This wiki page on OpenSSL explains this process a bit.

In terms of strength - generally, you want to avoid algorithms that are broken or can be easily broken (RC4, for instance), anonymous key exchange algorithms (Anonymous Diffie-Hellman, for instance), weak symmetric algorithms (DES), and broken hashing algorithms (MD5/SHA1). You may also care about the key size, and whether the algorithm maintains Forward Secrecy or not.


Messages encryption and decryption using Keybase.io

The encrypted messages doesn't have to go through their servers. Keybase just provides a means of getting a public key for a known username on x platform (for example, I have my twitter name and my github verified on keybase, people can use keybase to verify that my twitter is actually mine).
Keybase will provide the public key, which can be used to encrypt a message. Encryption can happen via the command line, or the website. The encrypted message can then be sent however you want.
From their website:

Keybase.io is also a Keybase client, however certain crypto actions (signing and decrypting) are limited to users who store client-encrypted copies of their private keys on the server, an optional feature we didn't mention above.
On the website, all crypto is performed in JavaScript, in your browser. Some people have strong feelings about this, for good reason

So, keybase never sees your encrypted message. If you don't want to store your private key on keybase, you don't have to. You can handle the decryption yourself or let keybase store your private key.

Could you please describes to me the security benefits of encrypting and decrypting messages using Keybase.io.

You get to verify a users identity, so you know that the person claiming to be me on twitter is actually me (as with github etc).Encryption is easy, as keybase provides the verified public key for you.

Do you think that using such thing will be secure

If you don't store your private key on the server, yes. Unless someone hacks your twitter/github etc. and changes your key proof, you're fine. If you do choose to store your private key on the server, you take the chance of keybase being hacked. Your call on that one.

where the encrypted message redirects through Keybase server to the reciever.

It doesn't. Encryption/decryption happens in JS in your browser. You can send the encrypted message however you want.


I'm going start by summarizing your want.

You want to:

Publically share information
The cannot be definitively associated to you
Unless you are present to defend yourself
In a way that cannot be reproduced by someone else

The answer would be a hardware based security solution for authentication, and an authorization system that requires the hardware based authentication in addition to another authenticator type (Something you know, something you are). So let's play with Github, as an example.

Github today allows people to create a Multifactor logon experience with a device such as the Yubikey. By enabling this feature, the access to your account is secured with a private key which cannot be shared and exists solely within your device. This, in addition to your password will always be required to authenticate to Github which you could even set up with a pseudonym of your choosing.

Once this is set up, you will have the ability to provide non-repudiation at your demand. You logon when you want to, and the logs indicating account changes can verify you haven't just thrown on the key to be impressive. You can show explicitly when the account was MFA enforced and even the last few logons. All good things.

The benefits of this approach is that only the holder of the Yubikey can actually access the account. This provides you the opportunity to share the data publicly without losing the ability to control who owns the original repository. Your interviewer could not login as you to prove that they know who built it, though you won't be able to overcome any trust that may exist. Meaning, if I trust your interviewer and they share who you really are that's beyond your scope.

Let me know if this is heading down the right direction and I can ellaborate further.

(instructions for yubikey configuration: https://support.yubico.com/support/solutions/articles/15000006469-using-your-yubikey-with-github)


How to use Nmap as a port knocking client?

The knock script sets the socket to 'non-blocking'. Non-blocking in python is the same as setting the timeout to 0 - that is, don't wait for a response. The TCP protocol defaults to 'blocking' - i.e wait for a response.

From Knock git the relevant line is: s.setblocking(False).

Try playing with the settings in nmap that set timeouts to 0:

https://nmap.org/book/man-performance.html

--min-rtt-timeout <time>, --max-rtt-timeout <time>, --initial-rtt-timeout <time> (Adjust probe timeouts) or --host-timeout <time> (Give up on slow target hosts) (suspect it will be the first one though).

Also, you might find that having wireshark running in the background to capture all the traffic to and from the server being useful, as you'd have a record of what was being sent when using nmap and knock, you might uncover something that way by comparing the results.


How can IT audit for installation of IIS Express?

The obvious answer (if we accept your premise) is: routinely port-scan your own machines to see if they are running any unexpected services.

I'm not too sure about the premise that the best way to defend against this risk is to try to detect use of IIS Express.  I wonder if you have considered an alternative approach, which is not specific to any particular product:

Developers should have full control over their machines, but those machines should be firewalled from the Internet.  There should be no open ports that are reachable from the outside Internet, without approval from security staff.
There should be separate machines for deploying services to the rest of the world.  These machines should be under control of the ops folks, and the ops folks should have procedures governing which services they deploy on those machines.  The ops folks will probably require some form of change control, if they're good.  These machines can also be firewalled with a firewall policy that matches the expected services running on those machines, as a safety net to catch mistakes.

I think these two steps will take care of the problem.


Google Chrome extension wants to be able to "manage apps, extensions...": reasonable?

Whenever you're considering whether to install a new extension it's important to weigh the risk with the potential reward.

This particular extension has the ability to modify the webpage on any page you view, it does this in order to allow you to share images with a single click, or copy things to onenote.

While this particular extension looks pretty benign, there's always the potential the company loses control of their extension.  This could happen through compromise of the account (attack) or by the company choosing to sell the extension to someone else.  There's been a number of extension authors recently that have decided to sell the extensions they have made, and a new company now can change it however they want, often without having to notify you whatsoever.

Is the ability to share an image with a single click, or save text to one note within your browser worth the risk?  That's something you have to weigh yourself.


JSON Web Encryption (JWE): should one verify the alg and enc similarly to JWS alg whitelisting?

Yes.

From JWT BCP:

  Libraries MUST enable the caller to specify a supported set of
  algorithms and MUST NOT use any other algorithms when performing
  cryptographic operations.  The library MUST ensure that the "alg" or
  "enc" header specifies the same algorithm that is used for the
  cryptographic operation.  Moreover, each key MUST be used with exactly
  one algorithm, and this MUST be checked when the cryptographic
  operation is performed.


Is it possible to track a SIM card even if the cell phone is turned off?

No.

A SIM card only provides the device with a unique identifier and related information. It does not have any in-built wireless capabilities. In order for a mobile device to be tracked, it needs to be connected (or trying to connect) to a cell tower. Both receiving and transmitting non-negligible amounts of RF requires power to be provided by the battery. If the device is off then so is the transmitter, regardless of whether or not the battery has any remaining charge.


How should I block unwanted domain names?

To prevent a negative impact on your SEO you can redirect any incoming content that isn't for your own domain to google to prevent the impression of duplicate content. How this can be done relies on your webserver.

// You can limit the answers of your webserver to a specific domain. It is explained here. You can modify the catchall entry with a redirection like explained here.

To solve this at long sight you should send an abuse Report to the responsibel Registration authority which registered the fake domain(s).

You can also check legal measures if the registrator was that dumb to use his real name.


How to detect whether my network's key is being attempted to be cracked?

Yes, if they are trying to break into your network in a particularly obvious way, but no for the general method of attacking WPA2 with a weak pre-shared key.

If they are trying to brute force into your network by repeated attempted logins (e.g., exploit the flaws of WPS - Wifi "Protected" Setup ), you can listen in on the network traffic, you would see the large fraction of unsuccessful login attempts.  (Or even easier your wireless AP logs failed wifi login attempts).

This would require setting up wireshark on a computer that has a wifi card that can listen in promiscuous mode to the traffic.  I've heard that this cannot be done in windows (not a windows user so I am not sure of this), so you may have to use linux or a Mac.

Granted most attacks on WPA2 do not work like this (excluding those on WPS).  Most attacks work by observing someone else's successful WPA2 handshake (listening in promiscuous mode) to a given access point (knowing the BSSID).  Then locally run take that handshake through a password cracking program until they find a match.  This cracking is done entirely by eavesdropping and offline cracking, so would not be detectable.

However, these attacks are computationally expensive and will only work in practice against weak passwords or slightly stronger passwords with a common SSID (like NETGEAR / linksys / default / dlink / wireless / Home). This is because the actual password used is a combination of the SSID + preshared key. Rainbow tables (precomputed tables) are generated for common SSID's, and when used, increase the speed of recovering your password. It is advised to change your networks SSID to something unique.

If you have a passphrase that is high entropy (not likely to be in any dictionary attack) and a unique ssid, these offline attacks against your network will be unsuccessful.


Can pre-compiled binaries be different than if someone builds from source himself?

The answer is, of course, that it's possible.  There are four major ways that can happen.

1) The binaries you downloaded include a vulnerability and weren't built with the signed source code.

Answer: Perform your own deterministic build based on the instructions provided at blog.torproject.org, which states "We achieve our build security through a reproducible build process that enables anyone to produce byte-for-byte identical binaries to the ones we release. Elsewhere on the Internet, this process is varyingly called "deterministic builds", "reproducible builds", "idempotent builds", and probably a few other terms, too."

2) The compiler you used included a vulnerability in your binaries, perhaps a specific implementation of the Ken Thompson hack from 1984

Partial Answer: This one's harder, though using different compilers from different sources and then doing careful analysis on the results to see if they have the same behaviors would be reasonable, if time-consuming.

3) Your OS or drivers are compromised.

That's outside of the scope of this answer.

4) Your CPU and/or NIC is compromised.

That's also outside the scope of this answer.


The way you are thinking about the problem is running you into trouble. It is not the DMZ or the tiers that improve security; it's the separation of the access and the data.

A DMZ is one way to separate access and data at the network level
3-tier architecture is one way to separate access and data at the application level

So, thinking about it this way, you can start to evaluate your risks and your mitigation options in terms of layers of separation and the risks of not separating the layers.

If there is a risk of someone gaining access to the DMZ network (server-level access), then you need to place the high-risk assets behind the DMZ. If the "app" portion of your architecture is not where the high-impact assets reside, then you can be justified in deciding to place the app tier (or, similarly, the web-app tier) in the DMZ.

Your decision matrix is based on the questions:

"what is the impact if this control fails?"
"what other controls need to fail in order for this control failure to have an impact?"
"what is the likelihood of this combination of controls failing?"

A DMZ and a tiered architecture add layers of control that give you options in case a set of controls fail. Whether the layers of control will have an effect is entirely up to your risk assessment.

Security and risk management is about applying layers of controls to mitigate the likelihood and impacts of an adverse event from happening. If a control does not affect the likelihood or impact, then it is a waste of resources.


How to remember a trusted machine using two factor authentication (like Google's system)

I don't think that it is entirely possible with just JavaScript/PHP (or some other server side language) to uniquely imprint/identify a computer.

Remember, whatever you do, someone with malicious intent can just copy the Chrome/Firefox user data directory to a similar system (same OS, etc). Indeed, that's the easiest thing to do, since you don't have to hunt for the cookies. JavaScript can't read anything outside these directories, so they have just duplicated the system.

However, you can use Flash/JavaScript to fingerprint the browser. Unfortunately, the browser fingerprint can change if the user installs fonts/etc. Besides, your users will have to allow the Flash/JavaScript to run -- nowadays quite a few people are disabling JavaScript due to the recent 0 Day exploit. You don't want to force your users to have to use these. Anyway, one can easily replicate a fingerprint by replicating the system (which takes time, but isn't too hard).

In the end, two factor auth is all about (a) having a password, and (b) having physical access to a device. If you are giving someone unsupervised access to your computer while logged in as you, part (b) is compromised anyway, in a different manner.

To answer your question, though:

You can put a unique GUID in a cookie
You can put another GUID in localStorage
You can associate part of the browser User-Agent request header with the account. For example, my User Agent is User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Ubuntu/12.04 Chromium/20.0.1132.47 Chrome/20.0.1132.47 Safari/536.11. From here, you can extract my browser name (which won't change), OS name and version (which will change occasionally), whether or not my computer is 32 bit, etc.
navigator.plugins -- This is an array of all the plugins installed on the browser. Maybe not a good idea for 2 factor authentication, though, since this changes often.

Note that all of these can be easily spoofed. It's just extra hoops for a would-be hacker to jump through.

Again, you can try using fingerprinting techniques that deal with reading the list of installed fonts, etc. Again, this can be circumvented, but it's much harder. You can also use JavaScript to store cookie-like files in random places on the computer (not sure if that's a good idea)

Edit: As Joel mentions in the comments, you should also have a way of revoking "trusted computers" (simply dissociate the GUID in your database). And this should apply when the password is changed as well.


Can HTTPS request parameters be seen by the PC client?

HTTPS protects against man in the middle attackes. Machines between the client and the server can not see HTTP GET or POST parameters.
However, other applications on the client (e.g. a TLS intercepting proxy) could potentially read the entire request, parameters included, in clear text. Or an application with sufficient priveliges could read the secret key from memory. So whoever controls the client - your users, or malware on their machine - will be able to read the secret key.


Is it effective to check how many times the same password was entered in fear of a string comparison timing attack?

You should already be rate-limiting login attempts after a few requests (temporary lockout, CAPTCHA, Clippy popping up and berating you, etc.). This is a common way to stop brute-force attacks, and it will also seriously cripple those trying to do timing attacks.

Edit:

Also, if you're hashing passwords and looking them up in a database, timing attacks shouldn't be very relevant. The attacker would have to be able to produce arbitrary hashes to gradually "home in" on the right one. This is very difficult!

Timing attacks will be more relevant for things like session cookies


Why doesn't `nmap -sn 192.168.2.1/150` show the hosts that are up?

Your first example uses the CIDR notation to specify the host range as a netmask.

But since /150 is an illegal value for an IPv4 subnet mask, nmap falls back to the largest plausible value which is /32 (because an IPv4 address only has 32 bits), making you scan exactly one host:

$ nmap -sn 192.168.2.1/150

Starting Nmap 7.60 ( https://nmap.org ) at 2017-12-30 19:45 CET
Illegal netmask in "192.168.2.1/150". Assuming /32 (one host)
Nmap scan report for easy.box.local (192.168.2.1)
Host is up (0.0026s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.01 seconds

The CIDR-noted range equivalent to

$ nmap -sn "192.168.2.*"

is

$ nmap -sn 192.168.2.1/24

because 255.255.255.0 has 24 leading 1 bits.

You can verify that assumption with more verbosity (-v):

$ nmap -sn -v 192.168.2.1/24

Starting Nmap 7.60 ( https://nmap.org ) at 2017-12-30 19:58 CET
Initiating Ping Scan at 19:58
Scanning 256 hosts [2 ports/host]
Completed Ping Scan at 19:58, 2.40s elapsed (256 total hosts)
Initiating Parallel DNS resolution of 256 hosts. at 19:58
Completed Parallel DNS resolution of 256 hosts. at 19:58, 0.06s elapsed
Nmap scan report for 192.168.2.0 [host down]
Nmap scan report for 192.168.2.1 [host down]
...
Nmap scan report for 192.168.2.255 [host down]
Read data files from: /usr/bin/../share/nmap
Nmap done: 256 IP addresses (2 hosts up) scanned in 2.47 seconds


Dots don't matter in GMail addresses.

Here's the link for your further reading.

You can add as many dots as you like in your GMail address, and you'll still receive that e-mail.

It also says that nobody else can create a new, dotted version of your e-mail address, so there can't be "other party" you mention in your e-mail.

Since there's no "other party", I assume the e-mail you received was meant for you.


How to figure out which open ports or services are insecure?

Step one - close all the ports you do not have an explicit business need for!

All open ports add potential insecurity - a closed port is a safe port.

If you don't know why a port is open, I would be worried - find out what service is running on it. If there is no business need, shut it down! If you can't find out what service it is, shut it down!

There are services lists for the most common services which run on particular ports, but really, anything can run on any port (pretty much) so you need to have a register detailing the port, the service, the business reason/function, the owner, the date it was implemented.

If you can't shut down services, use a firewall to explicitly block access to all but the services you do need.

Once you have done that, make sure that all your services are patched. One of the biggest sources of vulnerabilities is unpatched services/applications. Get yourself up to date now!


How to implement a workable Encryption Key Lifecycle

While there is no generalized solution, there are a few ideas on how to do that, based on what part of trust you're willing to give to the system:

decouple access keys from storage keys (store with random keys, which then are encrypted with access keys). make the system wrap new storage keys in your public key/identity-bound key for you to access. you trust the system to be honest and supplying new storage keys only to you.
trust re-keying software (one of nice ideas is to have compaction cycle in your DB, which removes obsolete records and re-keys everything, defragmenting your storage and updating every record sequentially) to have additional key to use at re-keying/compaction cycle.
trust the system to regenerate new keys and supply them to you over trusted channel (e.g. system signs every new storage key and sends it to you).
safely derive new key from old one with user being present with his private key for interactive protocol, in which parties (db and user) will derive new storage secret. requires online presence and being able to run key derivation protocol, which is only computationally cheaper than re-crypting everythign from key0 to key1 yourself.


Getting sudden spam emails with my name and city

One goal of modern spammers is to identify individuals who will likely be easy victims. Responding to such a random, unexpected message may indicate a certain naivety which can be lucrative when nefariously exploited. The random letters may be an attempt to throw off spam filters.

In regards to the email being added to an existing conversation, did that particular message appear to come from an email in the chain? It's possible the sender's address was spoofed. Perhaps the spammer gained access to email addresses from that company's address book and was attempting to appear more legitimate.


NMap scan can take a long time, try a small number of ports over a large IP range first.

Select a few of the most important ports to you and try those first.

Have you considered MassScan https://github.com/robertdavidgraham/masscan instead of NMap.


It depends on whether you are reading the post alone, whether you have access to the access logs which would give the source IP address, or whether you are a government agency with serious data collection resources.

If you are reading the post then no, you cannot get a location as there's typically no information on the source of the post other than the poster's username or handle.

If you have access to the server access logs then you probably can get the source IP address of the connection. With that information you can generally tell using a geolocation site or using whois lookups. That information may help you narrow it down to mobile provider or internet service provider, and that can often give you a general location. That general location can be pretty big though if the mobile provider or ISP has a wide coverage base. Also, if someone is using an anonymity service the IP address you see will not help you track them.

If you are a government with lots of resources and you want to know where a post came from you will likely have a database of all the connection information in your country and possibly others as well. That would include every mobile call, every mobile data connection, etc. Chances are this would be enough to track you, although anonymization may still work.