Is running SNMP v2c really insecure and can lead to compromisses?

SNMP enables an attacker to paint the same graph you are painting. "These are the mission critical systems they're worried about. They must be if they're being monitored." Whenever I see SNMP during pentests, I get happy since it minimizes the amount of time I spend looking for this. SNMP has enabled me to find networks I would have otherwise not discovered, when systems (Windows, Linux) run SNMP, they allow me to see the software on the systems, the usernames, groups, patch levels. So yes SNMP can be a security risk.

If you must enable it, remember the fact that the same things you want to see, are invaluable to an attacker. With that in mind, it pays to define ACLs on your switch to allow specific machines to access SNMP. E.g.: "enable from this ONE machine to SNMP, and block all other connections." Then you have to worry about sniffing the network. This does not get into SNMP when configured to write. An attacker can modify a switch/router/system. Long story short, while it is a risk, it can be mitigated with proper ACLs, network segmentation/isolation.


A neighbor took the Mac address from my router

Remember, just because you are using a wired connection, doesn't mean that your router/modem doesn't have a wireless connection.  Most ISPs that I'm aware of, give out a wireless modem/router these days since wireless has become more prevalent.

The person you spoke to at your ISP is correct in saying that wireless connections are relatively easy to crack, especially if they are left to their defaults, which I'm assuming that yours is since you said that you aren't using it.  You may want to contact your ISP to find out if you do in fact have a wireless modem/router and if you do, how to disable it.


How can I separate two OS's files with encryption without using TrueCrypt?

Relying on only one physical drive, you can split it into two partitions. Install Windows 7 on each one, and then use BitLocker (assuming you have Professional Enterprise or Ultimate [kudos to paulmorriss]) to encrypt the respective system volumes.

When you install the second Windows 7 OS in the other partition, it will prompt you to modify the boot loader to reflect both OSes. You can change the name that shows up during boot with the bcdedit command line tool (available in Windows Vista and later, it replaced the boot.ini config).

Edit: My apologies, I just saw the open source requirement. Reviewing the options listed here, there aren't many options that meet your requirements. The one that does is ProxyCrypt, but for your purposes of encrypting partitions, it needs to be used with other third-party tools (e.g., they state that Arsenal Image Mounter would need to be used as well).

If you want quick and easy, use BitLocker and separate partitions. If you want open source, check out ProxyCrypt.


Apache Server Maintains HTTPS Connection To Mysterious Server (Hijacking?)

I hate those kind of problems. There are so many places something could have happened.

I think I would just double check my config files - always a good idea to have a copy of valid config files. I use a GIT based tool to version all of mine. Then you can easily spot any unknown changes and back them out.

Then I would add the domain to IPTABLES and block it totally.


Honeypot SSH connection attempts with no interaction

I used to run a few honeypots and that's the typical pattern:

scans seek out valid services
processes bruteforce the services then immediately log out without taking action
attackers log in and perform actions

In many cases, the 3 phases could occur days apart from each other. IPs between the phases would never correlate, and the attackers would log in with the correct credentials the first time.

It was as though there were "scout" robots finding servers, botnets bruteforcing them, then verified credentials sold or distributed to attackers.


Ad-Hoc networks are just like regular ones: they are networks hosted by a machine (in this case your computer) that provide some networking functionality. Windows automatically disables wireless methods of file sharing and remote desktop without a password. The only thing bad that could happen (assuming you have a programmer on your trip, which you probably don't) is that your Minecraft server could get overloaded. Make sure you use at least WPA (WPA-2 if your friends' computers support it) so no one else joins it. Just make sure that you don't have a web server installed (if you do, make sure file uploads are disabled, or you might just want to completely turn it off). Just to be sure, I'd recommend using a regular account instead of an administrator account. Also, I regularly poll the Wi-Fi list to ensure no one is making an Evil Twin network (a network with the same name and password that is made to intercept packets). Finally, check the password of your network at howsecureismypassword.net to make sure no one nearby could easily get into your network without spending hours trying to hack into it. If you are going to be sharing files, use SFTP so no one could replace your file with a malicious file. If you have HomeGroup (or whatever it's called) enabled, make sure to disable it.


Does a TLS client needs to support one of the named groups (curves?) supported by the server for TLS handshake to succeed?

For elliptical curve (EC) protocol, all that is needed is for the client and the server to support at least one common curve.  However, if the client and the server do not support at least one common curve, they can try to agree on other protocols (such as DH).

But, in your case, it looks like the WAF supports a fairly large number of curves.  Even though x25519 is not one of them, there are plenty of others supported by the WAF, many of which that are older than x25519, so I don't suspect you'll have too many clients that are unable to connect just because you no longer support x25519.


Is it possible to mitigate risks of using a wifi connection that uses a self-signed security certificate?

Summary:

A wifi network with a badly-configured CA certificate (or a CA certificate that they only give to employees) is no worse than an open network with no certificate.

Would you still connect if it was an open wifi? If yes, then don't worry about it.

I'm assuming you're talking about the certificate that the wifi presents during connection? Something like this?

My understanding is that this exists to prevent SSID spoofing (ie an attacker parks a van outside your house and broadcasts a network with the same SSID as yours). When you connect to a wifi network, it can present you a certificate that cryptographically proves that it is the network that it claims to be (provided that you trust the Certificate Authority that issued that cert -- hence the UI thing about whether you trust the CA).

Would you trust it if it was an open network?

It sounds like the hotel configured this with a self-signed certificate. Maybe that's so hotel employees, or hotel equipment can download the CA cert and be sure nobody is doing an SSID Spoofing attack on them.

To you as a hotel guest, a mangled wifi certificate config is no more dangerous than a wifi with no CA certificate. So the question to ask yourself is:

Would you still connect if it had been an open network with no certificate?

If the answer is Yes, then don't worry about it. If the answer is No, then you probably know something about this network and what cert it should be displaying, and wouldn't be asking this question in the first place.

Note: this is different from installing a root CA cert into your OS or browser

One last note: We are talking about trusting a CA to identify the SSID during wifi connection. Note that this is different than trusting a CA to identify a website in your browser. If they ask you to download a CA cert and install it into your operating system, that would be a red-flag, because now they can impersonate any website that you try to connect to.


Can I Hook Up A Infected Drive To Another Computer?

would I be able to copy the files over to my laptop

If you are sure the disk is infected with virus, better scan the files and copy file only when it comes clean. Malware hiding frameworks and other similar tech(crypters, packers, encoders, binders, obfuscators or mix & match of similar tech) does a fairly good job of hiding the virus. Its always better to scan with multiple scanners to be sure of the file being free from any virus(malware). I suggest you give a try virus-total though many virus(malware) will not be detected by virus-total right away but it doesn't hurt to try the best possible way to avoid files which may detect infectious.

or would even connecting the drive trigger a virus?

It depends upon the nature of virus. Kindly consider taking calculated risk only if absolutely necessary, by studying the characteristics/specifics of virus detected.


Does WinRAR leave traces of temporarily extracted files?

Very good question. Yes, by default, WinRAR leaves traces of temporarily extracted files.

WinRAR does indeed create temporary files when opening them directly from the archive. It also performs a normal deletion once WinRAR is closed. However, deleted files do physically stay on the disk after you delete them. Normal delete operations only delete the file from the filesystem index.

Think of it like trying to remove a page from a book by striking its title from the index page - the page stays in the book.

WinRAR has a nice feature that securely wipes (removes the index, and the page itself from the book) temporarily extracted files after WinRAR is closed. By default, this feature is turned off. You can turn it on from the security settings window.

By default, it's set to 'Never', you don't want that. The option 'Always' securely wipes all temporarily extracted files, while the option 'Encrypted only' wipes temporarily extracted files only if they belong to an encrypted archive.

Important notes: WinRAR will also create temporary files when extracting files by dragging them to the destination. However, using the "Extract here" option doesn't create temporary files.

As mentioned below, it's also important to make sure that you don't close WinRAR before closing your file. I've just tested this behavior a Microsoft Word document and a PDF file. The .docx file persisted in the temp folder, while the .pdf file was wiped as soon as WinRAR was closed. So make sure you understand that this behavior isn't very reliable if you close WinRAR or if it crashes.


What tricks can be used to prevent debugging?

You could begin looking at Symantec: http://www.symantec.com/connect/articles/windows-anti-debug-reference

And there is a question in Stackoverflow about anti-debugging tricks.


To my knowledge, there is no difference in terminology between "adaptive" network security and "dynamic" network security. It is safe to believe that both reference the same thing.

Adaptive security, or real-time adaptive security, is a network security model that is able to respond to changes in and attacks against the network without human intervention. This is oftentimes implemented by utilizing communication between different security devices on the network. Here's an example.

Let's say an attacker attempts to send an exploit to a web server. An IDS on the target network is able to detect and stop the attack successfully. The IDS could then communicate with the firewall and tell it to block all incoming connections from that IP. This way, the attacker is locked out of the system completely and effectively blacklisted without the need for human intervention.


Access router if you don't know password

From your description, I suppose that your router was configured such that:

Using the WiFi entailed knowing the WiFi password, set to the password "blahblahblahblahblah".
When contacting the router over IP (whether from the WiFi, or from the outside -- a router, by definition, routes data, so it is connected to at least two networks), it is possible to access the administration interface with the login "admin" and the password "admin".

Then it seems highly probable that the intrusion came from the outside: someone, or some robot, simply connected to your router public IP address (the one facing the outside, allocated by your ISP, not the internal 192.168.0.1), tried to open the administration interface with the default password, and lo! it worked. You would not have been the first one to leave a default password. There is even a database of devices which have been left open. Maybe yours is referenced in there; you might want to have a look.

If your router was configured to deny access to the administration interface from the outer network, then the intruder must have come in from the WiFi part. Let's face it, "blahblahblahblahblah" is not the strongest password ever -- even if the rest of the WiFi was done properly (i.e. WPA2), such a password would not have lasted long against an attacker with a simple PC.

And, of course, there is always the possibility of a remotely exploitable security hole in the router software. Routers are, internally, small computers with software, which is not often updated (if at all), so they have bugs and holes. A simple search on "CISCO" in the published CVE uncovers 1418 entries.


How YubiKey Challenge-Response works "locally"?

The source code of password Safe is open source so you're free to do what I did: check.

A HMAC takes two inputs: the key and the data. What PS does wirth the ubikey is take your input as data and send it to the UbiKey. The key is in the UbiKey itself ans stays there.

So, the sequence of event is the following:

You enter your passphrase.
The software sends that passphrase to the ubikey
The UbiKey performs a HMAC using your passphrase as input and the (internally stored) secret key.
The resulting value is sent back to the application and is used for unlocking your database.

So the system is still safe as long as the various crypto elements are safe: the database REAL passphrase is the result of the HMAC operation, the HMAC is made of the secret key, which stays on your 2FA device and your own master password, which you enter through your computer.


Is it safe to publish a REST API client on npm even though the API is not intended for public use?

If you are providing a public API already, the security concern should be focused with the server side endpoints and not the client.

Yes, providing a public client to your API will allow any one to investigate your API, but anyone can already do that. The API will just make it easier to determine what endpoints exist and how they are used.

If you are concerned with the security of your API, you should focus your attentions there first. Providing a public client for the API doesn't increase your attack surface.


Possible to detect an/or shut off CryptoLocker by limiting total network bytes transferred?

Since a virus infected PC has to download (encrypt) reupload the entire file, and repeat the process for every network drive, is is possible to detect this unusually high bandwidth event? Is there a way to respond to it (via QOS or something?)

You're mistaken: the malware doesn't need to transfer the file. It uses asymmetrical encryption: the file is first (symmetrically) encrypted with a long, unique and randomly generated key and that key is the encrypted using only the public half of the decryption key.

Once that symmetrical encryption key is deleted, there is nothing left on your machine to decrypt the files and you never touched the key that will unlock it.

  I'm looking for a way to detect and/or limit Cryptolocker encryption by monitoring how much data is transferred (as it is encrypting files) and possibly set a quota on this transfer (QOS?).

Don't try to build your own: there are plenty of security systems that can assist you with detecting (and provide protection against) this and many other threats: antivirus scanners, IPS, IDS, NBAD, firewalls, etc. Any (smart) investment you make is these will be orders of magnitude more efficient than trying to jury-rig a protection on your own - especially if you do not understand the nature of the threat.


The APN is just a field that is sent to the mobile network when your phone establishes a data connection (also called a PDP context).

Equipment down the path can decide what to do with your traffic based on the APN, like routing it to different paths of the network, routing it to a company's internal network over VPN (companies can pay to have their own APNs which connect directly to their network, bypassing the need for an on-device VPN if they trust the mobile provider - which they shouldn't do).

The behavior you're seeing is just the result of years and years of technical debt - the alternative APN you're using may not even be in use anymore by the provider, it's just still there and they've forgotten about it, so they also forgot to implement traffic shaping on it and that's why you can bypass bandwidth limits. Since we're talking about a mobile carrier, it seems that mis-selling and implementing artificial limits like data caps is more important on their roadmap than cleaning up technical debt.

On a properly designed mobile network there is no need to have more than one APN as the network can differentiate between subscribers by their SIM's ICCID (which is also sent to the network and known to the equipment managing the PDP contexts) and assign policies regardless of which APN is in use. This removes confusion and prevents customers accidentally/maliciously using a different plan which could result in an incorrect policy being applied or extra charges.


The blog you linked says to use the SSL Labs test for verifying and, if vulnerable, apply the patch supplied by your vendor.

If the company wrote their own web server, they are the vendor and will have to write their own patch.


What exactly was "'dotty' and 'dashy'" Morse code?

The aim of encryption is to produce a message that cannot be read as is. The old Cesar cipher was a simple alphabet shift. We now find it trivial, but when you see a bunch of characters with no evident meaning, you can suppose that a real message is hidden but without knowing the algorithm deciphering it is not a trivial task.

The rationale behind dotty or dashy is that the enemy will see a sequence of dots and dashes which has no direct meaning because is looks like incorrect Morse code, especially if you do not add any space between characters. But it is too simple to resist for a long time to an experience cryptanalist, even without the help of a computer.

On an historical point of view, AFAIK, the older code is probably Cesar's cipher that was indeed used by the Roman emperor, and which was later improved with Vegenere's code for which the shift varied according to the letters of a word (the key) instead of being a constant.

Both can be easily used without any machine.

A rather strong code that existed for a long time and requires no computing is the use of a full book as a key: the sender searches the words they want to send in the book, and replaces them with the triplet (page number, line number, word position in the line). If the message is short enough and the book long enough, it is possible to use different triplets if a word is repeated which hardly hardens the code. But it is hard to use in an operational point of view because if you want to use an uncommon word, it could not be present in the book...


If you want to connect to the old VPN through the new VPN, it's best to start by canceling your account with the old VPN. Get an account with the new VPN, and use it for a month or two.

Then get a new account with the old VPN, without revealing any connection to your old account. Never connect to their website or VPN servers except through the new VPN. Use a new email address that's not linked in any way to your old VPN account. Pay for the new account with your old VPN provider using cash through the mail, or with thoroughly anonymized Bitcoins.

It's very easy to anonymize Bitcoins by using mixing services (such as the Blockchain wallet, BitLaundry and Bitcoin Fog) via Tor among multiple Multibit clients in Whonix instances.

It's easy to nest VPNs, as Pseudo Reality noted, by using one in a VM host machine, and another in a VM. For more complex configurations, one can use pfSense VMs as VPN clients, and combine them with Whonix and other Tor gateway VMs.


"Hacking" account when someone uses your email?

If I were to confirm the account, and the person were to start using it, wouldn't I essentially have a "trojan horse" of sorts where I could simply reset the password and take control of the account whenever I felt like it?

Given that they are not using 2-factor authentication, yes (though I don't think "trojan horse" is the correct term). They would be able to start using the account when it is confirmed, but you would have the ability to reset the password, and then log in as them.


Hardware security modules

Running code in a physically-protected chip such as a HSM or a smartcard is not about protecting from software bugs. If there's a software bug in a HSM, it can be exploited just as any webserver, laptop, smartphone, whatever. The difference between a HSM and a PC is that with physical access to a PC, you can just boot from a USB stick or swap out the disk. With physical access to the outside of an HSM, you still have to break in, and HSMs are designed to self-destruct when you make a serious attempt at opening them.

Running a browser on a Raspberry Pi

A PC is a “chip-based system” as much as a Raspberry Pi. There's no fundamental difference between them: a Raspberry Pi isn't somehow “more secure” than a PC.

More people use PCs, so PCs are a more valuable target to exploit, so more people try to exploit PCs. PCs also have a heavy burden of historical compatibility and a large variety of software, which puts them somewhat more at risk. But if people routinely ran browsers on Pis instead of Pentiums, there'd be more exploits out there for Pis.

Moving the browser to a different machine isolates it. But what do you gain? A lot of exploits are delivered through the browser. Often the browser itself is the target. It has access to the network, so it's a valuable target to spread the infection to other machines. It's how the user interacts with a lot of things, so it's a prime target for thieves and scammers. No matter where you put your browser, if it's infected, you've lost.

Randomizing code

Randomizing code in some way is a defense technique, but it only makes exploits harder, it doesn't make them impossible.

For example, some modern operating systems practice address space layout randomization: each time a program starts, it's loaded at a different random address. This means there are things you can't do in an exploit, such as refer directly to the address of a piece of code in the original program. It doesn't make exploits impossible: there has to be a way the program can find its own pieces (for example, a short relative jump will keep working just fine), and if some piece is hard to find the exploit can search for it (it's a common issue even without ASLR because often the exploit code itself will be loaded at an unpredictable address).

Randomizing code in the compiler wouldn't buy you much, and it's expensive. All these forms of randomization make debugging harder. If you randomize before distributing the program, you have to manage the distribution and maintenance (updates) of all these different versions. And security-wise the benefit it minimal because in the end the program still has to do the same thing.

How hardware helps with security

For run-of-the-mill systems (not HSMs and the like), the role of the hardware is to enforce isolation between components. It's a hardware component, the MMU, that makes it impossible for a program to directly access another program's memory. The CPU design also makes it impossible for ordinary programs to directly access hardware peripherals, they have to go through operating systems interfaces for that. The hardware has to be used correctly: it's up to the operating system to set up the MMU tables correctly and so on.

You can't put too much intelligence into the hardware. The more you do, the more there's a risk that there'll be a bug in your design. Hardware bugs are pretty hard to fix. So the hardware provides some basic capabilities, and the complexity is handled in software as much as possible.


What does scorecardsresearch.com/beacon.js - added by Disqus.com - do?

Am I essentially giving scorecardresearch.com access to my users and user's cookies for my domain, since the script tag is on my page?

Yes. Any script included in your page either directly or indirectly (via disqus) has full access to interfere with the user's experience for everything on the hostname it is included on.

Stealing client-side (non-httponly) cookies is only one potential attack - if they wanted to, they could include a JavaScript keylogger to intercept all keypresses on your site, steal passwords, make the user automatically delete their account, and so on.

You will have to decide how much you trust Disqus and their partners, and gauge how sensitive the material on your site is, to come to a conclusion on whether this level of access is an acceptable bargain for the benefit of having a chat system for free. I'm a paranoid sort who can remember back to the days when TMRG (scorecardresearch) had their MarketScore spyware silent-installed in software bundles, so I'm not keen, personally.

If you're worried about this but still want to keep the chat feature, a potential workaround might be to include the chat in an iframe served from another domain that doesn't get scripting access into your main site domain.

  As far as I understand beacon.js along with cookies does a bunch of tracking of visitors

Yep.

  What does this report mean?

It's an automated vulnerability scan of the beacon service; it hasn't been processed manually to rate how much of a problem the detected issues actually are.

From the issues listed here we have the ability to inject unescaped HTML content into files from scorecardresearch.com. That would normally be an XSS vulnerability, albeit mitigated by the files that are being injected into being JavaScript files. So you could inject into scorecardresearch.com if you could make some visit that address using a browser that can be fooled into thinking the file is HTML by the presence of content like <html>. This is 'MIME-sniffing' and it's typically more of a problem for older browsers.

In any case, this probably doesn't affect you. You are including the script from scorecardressearch into your site's security context, not using scorecardresearch's potentially-compromised own context. Including a file as a <script> doesn't give MIME-sniffing any chance to misinterpret the string literal content as HTML, and there's no evidence of any holes in the script that would allow content to break out of the Javascript string literal (unescaped quote mark).


What is a good backup strategy against ransomware?

Have multiple backups with at least one offsite. The time scale will depend on your usage. For example, many businesses will use daily offsite backups. For personal use, weekly or monthly may be sufficient. You will minimize your risk this way.

I doubt the ransom-ware will wait long to see if it can infect your monthly backups, because the longer it is on the system, the more likely it will be discovered/removed.


How to encrypt user data in app using Google Sign-In

Long story short, you can't unfortunately.

You could ask a user to provide an encryption key the first time they login, then store that encrypted with the token, but of course the token will change if they reauthenticate (as you identified), so they would have to provide their key again at that point.  For you to be able to decrypt the user data you'd have to first ascertain the token to decrypt the key, which depending how your application is set up and the access your DBAs have might be enough.


Will new data written to disk while BitLocker is encrypting the disk be encrypted?

The drive will be treated as a whole, since it's a Disk/Volume encryption (unlike file or system encryption), everything that goes into the disc will be encrypted as it goes in.

UPDATE

Behavior confirmed in Microsoft Tech Net

Credits to Chris Vasselli


If the passwords are salted and hashed then there is no real value in them to an attacker. Go with whatever is simplest to manage from a development and maintenance point of view.


Communication between two open endpoints, is this secure enough?

You are relying on "security through obscurity", and implementing this type of security is never a good idea.

You can create a vastly more secure and easier solution by implementing SSL (or TLS) on your solution. Here is a very good tutorial on Stunnel:

you install stunnel
create custom certificates
encrypt everything transparently

Using stunnel you can treat all data in clear text, without adding complexities like encryption, encoding or authentication.


this is false positive because I am not using this version on the server?

Yes and no. It's an issue because the vulnerable version is installed, and can be loaded at any reboot by the user/operator. But at the moment, the running kernel is not the vulnerable one. So it indeed have the vulnerable version installed, but don't have the vulnerable version running.

  Where can I check if kernel-3.10.0-1062.4.1.el7.x86_64 is the latest kernel version?

If you are using RedHat (it looks likely), you can use yum to see the latest version:

yum -v list package_name --show-duplicates

Installed Packages
kernel.x86_64                    3.10.0-123.4.el7                  @RHEL-76-x86_64-updates
kernel.x86_64                    3.10.0-234.1.el7                  @RHEL-77-x86_64-updates
Available Packages
kernel.x86_64                    3.10.0-345.1.el7                   RHEL-77-x86_64
kernel.x86_64                    3.10.0-1234.5.6.el7                RHEL-77-x86_64-updates
kernel.x86_64                    3.10.0-1345.8.9.el7                RHEL-77-x86_64-updates
kernel.x86_64                    3.10.0-1579.2.4.el7                RHEL-77-x86_64-updates

It will show you the installed version and some available versions.


HMAC: How unique does a nonce need to be if the Date is also part of the signature?

You need to take in consideration the allowable time window (to compensate for Clock drift). If you allow Date's with a time window of plus/minus 10 minutes (total: 20 minutes) you need to use nonces that are unique on the whole time window, and you also need to store spent nonces from that time period.

To avoid a race situation where a nonce is being deleted from the "spent" list Before the Date: header of the used nonce has became invalid, it would be recommended to store the spent nonces from the last 40 minutes, and also use nonces that are unique for 40 minutes.

Then you have a practically a watertight solution.

In other Words, if you would allow a nonce to be reused after 1 second, a attacker can just resend the old request with the old date header, since if you allow a time window - which you must because you cannot ensure the client Clock is synced with the server, then you would accept a request with a spent nonce.

If you reallywant a good nonce, use H(Time, Nonce) where H is a decent hash function. Then you can use "non-unique" nonces as long as you dont generate 2 equal nonces the same second. Then you get unique hashes to use as nonces.


It depends on how precise you want to locate them. There is no commercial solution that can do this on premise that I´m aware of(Because GPS etc. suck indoors).

What comes to my mind is triangulating them with several wifi antennas in a selfmade solution. Your brother would have to set up several wifi antennas in the building that are in monitor mode and report to central station. As long as all devices have wifi enabled and you know their MAC Address(or wifi can be turned on remotly by MDM) you can triangulate them

For Example (please forgive me my non existant Paint skills):

You check all your APs in Monitor Mode and the MAC adress of the device you´re looking for is recognized by AP1-3

AP1 gets a damping strenght of -50db
AP2 gets a damping strenght of -40db
AP3 gets a damping strenght of -45db

Now you need a little estimation because the signal strenght depends on things like wall thickness etc but you can take a max and min lenght for any given strenght (+/-3 meter of what you expect for example).
In this example AP1 is in a part of the office with no thik walls, etc. AP2 is in a small office with concrete walls and AP3 is positioned somwhere in the hallway (therefor the variance in min/max distance).

Now you´ve got 3 min/max lines for the given 3 APs and they only overlap in the area marked green which is the location of the device.

I know this approach is far from precise but I think if you script and test everything properly (especially the variance in estimated lenght) this would be able to locate quite precisely.


Physical mechanical examples of "M-of-N" locks?

There are real-world multi-key locks made for this purpose. The most common have two separate cores that are internally geared to turn together, which require both keys be present and turned simultaneously.

Other designs have a single key way and require the two different keys be inserted sequentially. Here’s an explanation on using the latter: https://anemo.eu/how-do-dual-key-locks-work  This tubular lock requires each key be turned a quarter turn each. Internally, this might be done by boring a groove linking one pin’s hole to span the first quarter turn, ignored by the first key; then boring a different pin’s hole spanning the next quarter turn, which will be ignored by the second key; the rest of the pins would match. The keys would have to be used in order to unlock it, and relocked in reverse order.

Neither of these designs inherently solves the m of n problem where m < n. That can be solved with a standard industrial lock-out hasp with n physical padlocks.  Each key holder is then given a unique subset of physical keys to open one share’s worth of padlocks, using a secret sharing scheme.  Note that this approach does not scale well in the physical world, as the number of padlocks and keys grows exponentially with n.


It means that rather than trusting a central authority for validating the PKI, you are utilizing your own means to determine that a public key is valid.  Pinning allows removal of the trust of a central authority and instead takes that responsibility on directly.

The "problem" that it is trying to solve is relying on third party trust, however it requires that proper steps be taken to ensure first party trust and to make sure that revocation is not impeded if the pinned certificate/public key's corresponding private key is lost.

Many techniques can be used for establishing the trust, but some common ones are distributing the pin with an application that requires communication or verifying via an offline side channel.  Revocation checking could be done through operating a revocation list similar to how a CA would normally do so, though this takes some more setup to do properly.

There isn't a practical difference between certificate and public key pinning as a certificate is just a public key with details about the holder of the private key.  Pinning just implies trust of that cert/key.


SFTP, FTPS and SecureFTP differences and security implications

There are 3 different protocols commonly used for transferring files over the Internet, and they are commonly confused with each other:

FTPS - an extension to the FTP protocol to support using FTP over SSL/TLS. This is typically based on a client-requested negotiation, and there are specific FTP commands to request/enforce/implement the encryption using SSL.
FTP over SSH (commonly called SecureFTP) - tunneling standard FTP over a SSH connection. Take into account that it is a bit more complicated to force the data channels to continue tunneling over SSH, even if the control channel is tunnelled.
SFTP - This is a completely different protocol, SSH File Transfer Protocol. This is not related to FTP, but is a completely different protocol. SFTP is actually a sub-protocol from the SSH protocol suite, i.e. a SSH extension (however I understand that it can be used separately, too).

Advantage of FTPS is that it is similar to HTTPS - same type of certificate, etc. Many web servers support FTPS natively, and thus it is often "simpler" to set up and have admins up to speed faster.
SFTP has advantage in *nix shops, that are typically already more SSH-friendly - if they already set up a public SSH server securely, its pretty simple to add SFTP functionality.
Note that SecureFTP (FTP over SSH) is NOT trivial in any case (even if you already have the SSH set up), and I haven't seen it in use by security-conscious orgs (that's not to say it CAN'T be, but isn't commonly).


staying not signed in: is it the safest procedure?

Risks of keeping logged in:

CSRF and XSS attacks could be used to compromise your sessions, if the site in question is vulnerable.
If the application uses weak or predictable session tokens, yours could be brute forced.
A physical attack (e.g. laptop stolen), could possibly allow access to all your logged in sessions. This could be mitigated using disk encryption, or if using a browser that encrypts cookies like Chrome it can be mitigated with a strong password on your OS account. Both mitigations assume your laptop is locked/logged out at the time of attack, preferably logged out to prevent cold boot attacks from reading the key from memory.

Risks of typing the password each time:

You may be vulnerable to phishing unless you diligently check the domain and the HTTPS padlock each time.
Keyloggers may get your password, although if they do this your machine is compromised therefore you've already lost.

I would suggest the use of a browser based password manager to mitigate phishing, as your password will only be filled if the domain matches, although I've not seen any yet that protect against ssl strip style attacks (that is, they validate the domain, but not that the protocol is HTTPS).

Risks of a password manager:

If they autofill password boxes without prompting, an XSS attack could grab the password should the site be vulnerable.
You're trusting software or service with your keys to the kingdom.
You could be at mercy to any vulnerabilities in the client-software or server-side storage (if applicable).
All your eggs could be in one basket should your master password be compromised.


Installing applications with different user accounts on linux

There is no standard method for installing applications. Most applications will set themselves up such that their config files are only writeable by a single uid. Certainly Oracle does this. You can amend the permissions later - but this usually needs to be reapplied whenever you install upgrades.

It's good practice to restrict permissions based on a least privilege basis.

It's NOT good practice to share accounts

To resolve this potential conflict where more than one user may require access to run programs / alter data, then the solution is to setup a group containing the users whom require that access and modify the permissions accordingly.

Alternatively you can use sudo - but IMHO the group based solution is neater (preserves uids).


Any system connected to the internet is going to get scanned, and often. If your system was behind a firewall which was set up to only allow outgoing connections then you would not be seeing these messages. This leads me to believe that you either have a direct internet connection or you are behind a firewall but it is set up to forward packets to your system.

The best thing you could do to protect your system would be to either put a firewall between your system and your internet connection, or if you already have one to configure it to only allow outgoing connections.

EDIT: Poster says his PC is directly connected to the internet

The main issue with your setup is that all operating systems have zero day vulnerabilities which could be used by an attacker to take over your system no matter what software firewall and antimalware software you are running. These are often integrated into automated software which scans the internet trying to infect as many systems as it can find, so even if you are extremely diligent about installing every single software patch you are vulnerable. The only way to reduce this risk would be to purchase a hardware firewall to protect your system.

Regarding your concerns regarding your employer it's unlikely that they've been able to install monitoring system behind your back, however monitoring software could have been installed as part of a wider software package, so if you were asked to install software on your system it is possible that it could be monitoring you. Also, java applets could hook into your camera, microphone, or browse your files. I'd say the likelihood of that being done is low if taken across all employers, however you have a better idea as you work for them. Plus they seem to have made statements to the effect that they are monitoring you, which could just be them joking but maybe not. If you are being monitored and you live in a place where there are employee laws that will protect you then it's a matter for law enforcement, if not then you need to take steps to protect yourself.

What I would do is either buy a second system and do employer work on that second system. You can physically disable any camera or microphone on it and as long as you keep it purely for work your employer will never see anything personal. If you cannot do that the other option would be to create a virtual system within your physical computer and use that for employer work. You can configure the virtual box to have absolutely no access to microphone or cameras on your physical system, and the virtualization will allow you to separate your personal and work data within one physical system. Just be sure to strictly limit the access from your work system to your personal system no matter what method you use.

Of course you could just tape over your mic and camera if you are worried about the physical surveillance aspect.


How bad is using date to generate a "random" password?

Let's assume I know the day or week you created your password, but not the exact time. This assumption seems reasonable:

Many online services display account creation dates
Many online services publicly recommend changing passwords due to breaches (I can guess that you changed your password within a week of the service's last publicly disclosed breach)
Many people change passwords "just to be safe" if something fishy happens, send a spoofed email to the victim and there's a decent chance you'll get lucky
In the event of a database leak, many services store the date of last password change (for example to enforce the (now obsolete) 3 month password change type of requirement)

You're password from urandom has log2(6432) = 192 bits of entropy. As passwords go, this is excellent.

If we assume I know the day you generated your date | md5 password, you have log2(60*60*24) ≈ 16.4 bits of entropy (86,400 possible passwords); this is very bad. Even with unusually strong Argon2 parameters that require 1 second per attempt, it would only take 1 day (at most) to crack, and an MD5 hash could be cracked almost instantly. In the event of an online attack rate limiting may help, but I certainly wouldn't rely on it (the attacker could use many IPs and spread out guesses over several weeks).

If I only know what week you generated the password it's only 7 times better, which is still nearly instantaneous when cracking an MD5 hash.


What causes the descriptive text in HTTPS lock icons?

That's called Extended Validation Certificate.


Why do I need root privileges to send a raw packet from a UNIX machine?

The security model in UNIX is traditionally centered around having hardware and network controlled by the network administrators and then having unprivileged users separate from these administrators on the network. In other words: the network and the hardware are considered trusted because they are controlled only by a few selected administrators. This security model can also be seen by the simple security approaches taken by older services which rely on using privileged ports (i.e. port <= 1024) as part of their security - assuming that unprivileged users cannot bind to such a port. They also rely on IP based authentication - assuming that the use of IP addresses in the network is fully in control of the administrators.
Allowing unprivileged users to use raw sockets would break these security assumptions, since with raw sockets anything could be done in the network, like using privileged ports, spoofing IP addresses etc. That's why it is not allowed.
Note that this simple security model is hard to enforce in today's current and complex networks. In times where mobile clients, user controlled devices (BYOD), hardware of different kind (i.e. printer, phone, coffee machine) from lots of different vendors and with often weak security are part of the network, it is kind of impossible to enforce these traditional security requirements. That's why there are new approaches like Zero Trust Networking, which assumes much less control of the underlying network and the systems inside it.


Is SSH2 still vulnerable to man-in-middle attacks?

There's always going to be a chicken-and-egg problem -- how do you trust the ssh key of the server you're connecting to if you've never connected to it before. Some sites publish lists of all their SSH keys, some go further and PGP-sign these lists, but it all ultimately comes back to the age-old problem of distributing trust.

The latest and most promising approach is to publish SSH fingerprints for the servers in the DNS records that are then signed using DNSSec. E.g.:

$ dig +short -t sshfp fedorapeople.org
2 1 9EB13E6BEE80F5D56B4E9A029DC53CF00EF14045
1 1 5829B0460C2E9296BDBD835416C2615DCF80D22A

You can then add the following to your ~/.ssh/config

VerifyHostKeyDNS yes

You have to also configure DNSSec on your resolver for it to make any difference.


How to get attacker mac address aireplay-ng

Deauth attacks require that the attacker spoofs the MAC address. What you are asking is to somehow get the MAC address of the attacker even if it is spoofed.

This is not possible from packet captures.

There is a potential that if the attacker hangs around long enough and sends packets from the real MAC on the network, then you might be able to correlate that traffic to the deauth traffic and conclude that the MAC is the attacker's. But there are a lot of things that would have to occur for that to be possible.


Android Applications hosted on 3rd party Sites

Most of those 3rd party sites are hosted and managed in countries that do not really care about software licenses and/or abuses or any other kind of legal complaint :)

You can always try to contact the owners of those 3rd party application stores, but don't expect too much from it. And also, it'll be a never ending task.

There is at least one thing that you as a developer are able to do. Is making the tampering of your application a little bit more complicated, by adding integrity checks that will trigger a message of warning every time a user opens the application.

Please have in mind that this is also bypassable, but if you perform code obfuscation (i.e. Proguard) in addition to those checks, it'll make the work harder to those people tampering and/or re-distributing your applications.

You must also have in consideration that these recommendations are just mitigations, but you won't be able to completely stop this, as some markets as China completely rely on those 3rd party markets to get the applications. So there will always be someone re-distributing for them :)

Hope I helped a little !


How can I secure a network share from the insider threat?

If you want to prevent an insider from stealing your data, I'd guess you have only one strong defense: don't give them access to the data.  In other words, use access control to limit their access to the data.  If the insider has access to all the data, prevention is really hard.

One alternative is to detect signs of such misuse: e.g., where someone has accessed far more data than you would expect they would legitimately need for the purposes of their job.  Detection is imperfect, and doesn't necessarily provide any great way to recover from such a leak, but it might provide some deterrence.


Reducing the success ratio of email harvesting

I don't think that your idea is effective to pollute the spammers lists with so much fake entries that the costs of sending spam increases noticeable. But as far as I know such fake accounts are still used to fight spam, although in different ways:

Since spammer don't handcraft a new spam mail for each recipient but base mails on templates such dummy accounts are actually used to get early access to new spam templates. This knowledge can be used to increase the precision of existing spam filters and thus better protect legitimate addresses.
Similar thus "honey accounts" are used to rapidly get new sources of spam and quickly update IP blacklists. Again this is used to protect legitimate accounts.
And since such addresses are not only used for spam but also for malware delivery these honey accounts help here too to detect new malware campaigns and to protect legitimate accounts.


First, the options for generating a key with gpg provide you an option for creating your Master (certify) key at the same time as an encryption subkey. These are the options for (1), (2), and (9). Otherwise, you are creating one key and setting the capabilities on it.
You need to consider the trade-offs of modern cryptosuites and the software that supports them. Most GPG keys today are still using a root RSA key in order to maintain backwards compatibility with client software that does not yet support ECC. I have yet to see a smartcard or a secure element that offers Ed25519 curves. If you are using an HSM you are probably still restricted to NIST curves, and P-256 at that.
Of the ECC curves, the NIST curves have the most support. [Note: You can read this question to understand the concern around NIST parameters: https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters]
If I were using smartcards, I would use NIST curves with the largest key size the smartcard would allow. If I were not using smartcards, I would use an Ed25519 curve.


Attack vectors opened simultaneous wireless and wired networks

Edit (11/14): As far as I know, there are no significant risks to having both a wired and a wireless network connections open at the same time, beyond the risks implied by each one individually.

There are risks with having a machine connected to both an internal-only network and to the Internet: it partly defeats the purpose of having a firewall to separate your internal-only network from the outside Internet.  The purpose of a firewall is to have a single chokepoint that controls the security perimeter.  If you have a machine that's connected to both the inside and the outside, that machine now becomes part of the security perimeter.  For instance, if that machine gets compromised, now your entire internal network is exposed to the attacker.  For this reason, it's generally not recommended to connect machines to both networks.

If malware compromises this machine, the malware could set up a route like you mention -- but if malware compromises your machine, it could just directly start attacking your internal network without modifying any routes.

I want to emphasize again the importance of being clear in your mind about which aspect of the networks is relevant.  For instance, in this case, I think the "wired + wireless" part is not a concern, but "internal-only + Internet-connected" part is a concern (and "not-under-your-control + under-your-control" would also be a concern).  I don't know what you mean by "regulated", so I'm ignoring that aspect.

I don't think there's any need to go around creating/imposing some special restriction on your hosts to block access to wireless while they're connected to a wired network.

There is one mitigation I can mention to you, for consideration.  One organization I'm familiar with has two separate internal networks: one network for non-mobile devices, and a second network for mobile devices (laptops, smartphones, etc.).  The first network has full access to our internal servers, and only supported wired (not wireless) access.  The second network has semi-limited access to some (but not all) internal services.  It supports both wired and wireless access.  All mobile devices (laptops, etc.) are automatically directed to the second network (even if they connect via Ethernet, they are still connected to the second network).  The purpose of this mitigation is to reduce the spread of malware: empirically, sysadmins noticed that people would often take their mobile devices while traveling, get exposed to malware from some other network (e.g., at a hotel that doesn't have our firewalls), get infected, then bring their device back home and connect to one of the internal networks and infect other internal machines.  This isolated-network design is intended to slow down the spread of such malware.  Today, it might not be as effective or realistic, but it's something you could consider.  However, the best way to mitigate your risks will likely depend intimately upon your particular business and your particular situation.

My earlier answer to the original question:
This question is confusing.  It seems to me you are confusing/conflating several different concepts:

Communication medium: wired vs wireless.
Connectivity: an internal-only network (that can't reach the external Internet) vs a network that's connected to the Internet.
Administrative control: a network under your organization's control, vs one that is not.

These are independent features.  They're not tied to each other.  Your question seems to start from a faulty premise: it seems to equate, e.g., wireless with "not under your administrative control and connected to the Internet" while equating wired with "internal-only and under your control".  If that is truly what you were thinking, it is a misconception.  You can have a wireless network that is either under your administrative control, or not; and is either connected to the external Internet, or is not.  You need to analyze the effect of each of these aspects separately.

Each independent axis affects the risk in a different way:

A wireless medium is potentially riskier, because it enables eavesdropping, interception, and message injection by anyone who is within radio range.  This risk can be mitigated or eliminated by using proper security, e.g., WPA2 with a strong key.
Internet connectivity adds risk, because there is the potential that people visit a malicious site and get attacked (or otherwise are attacked by malicious entities on the external Internet).  This risk can be somewhat mitigated by using firewalls, endpoint protection, and device hardening, but only to a limited extent.
Use of a network outside of your administrative control adds risk.

So, what should you do?  You should figure out what your business requirements and needs are.  You should identify what the threats and risks associated with the networks are.  Then, based upon a cost-benefit analysis, identify controls to mitigate those risks so the risk is at an acceptable level, given your business's requirements and risk tolerance.  Saying anything more specific will depend heavily upon your particular organization and your particular situation.


The key should be the same size as the hash output. In your case you are using SHA-256 so you should use a 256-bit key (which equals 32-bytes that you mention).

The HMAC algorithm is really quite flexible, so you could use a key of any size. However, if you only use a 128-bit key then there is no point using a 256-bit hash; you might as well use a 128-bit hash like MD5.

SecureRandom in Java is quite adequate for generating keys for this purpose.


Is it possible to securely store passwords using reversible encryption?

Reversible encryption is not commonly used for passwords because the specific requirements and parameters of password authentication are incompatible with the weakness of reversible encryption.

The primary weakness of reversible encryption is simple: if the key is compromised, the encrypted data is compromised, period.

Passwords are used all the time, whenever users log in.  Therefore, the authenticating process must be able to access the users' credentials all the time, in an automated fashion, without obstructive controls.  That means that the key for reversible encryption needs to be on disk or in memory all the time.  If that program, disk, or memory are somehow compromised, then all those reversibly encrypted passwords are all compromised in one fell swoop.

In contrast, consider the use of non-reversible hashes.  If the program, disk, or memory are compromised then the attacker gets the "locked" hashes, and there is no key.  They can then attack further - known ciphertext attack, brute force, etc - but they haven't "won" yet.

We do use reversible (let me say keyed) encryption all the time - disks, files, email attachments.  What these uses all have in common, though, is that they encourage (if not require) human intervention to provide the key.

I'm not sure why you're asking about this, but what about a hybrid model?  Consider that it might be reasonable to store both reversible and non-reversible ciphertext for user passwords.  When passwords are created, store two enciphered versions: One created with a one-way hashing function, and the other created with an asymmetric encryption algorithm ("public key cryptography"). All automated authentication processes use the non-reversible hashes for authentication purposes.  Keep the "public key" half of the pair on the system for use generating the enciphered passwords, and store the "private key" half of the pair offline.  In the event the password plaintext is needed, take the encrypted password offline and decrypt it with the appropriate key.  As long as the decrypting key is not accessible to the authentication system, then an attacker cannot take advantage of the fact that you used "reversible" encryption to store plaintext passwords.

That'll only help if your need for accessing the plaintext passwords is not an automated need, of course.  But it seems like a nifty idea to me.


Is problem with string length in token (read password) randomization a security flaw? Is there any impact for the same?

As long as a truly randomly generated password is at least 6 characters long, it passes the NIST's password standards, which is regarded by many to be a good bare minimum standard.  (A user-generated password should be at least 8 characters long, because it's much less likely to be randomly generated.)  Your own security team should decide on reasonable minimums for your organization.

The most important factor in any secure password is how random it is.  If we assume that the passwords are generated in a secure way, then varying their length will tend to improve the security of the overall system.

Applying Kerckhoff's Principle, that everything in a system is public knowledge except for the key -- in our case, except for your password -- we must assume that an attacker will know the length of the passwords that such a system generates.  If they can't be certain of the length because it can be anywhere from 10 to 95 characters, then this increases the search space, and can increase the time it takes to brute force a password (though if you're unlucky enough to get a very short password, it might decrease the time).

So, outside of any other considerations, the security of a system is not meaningfully impacted by having a random password length, when that password has a reasonably long minimum length.

You state in your comments that the emails are always sent encrypted. This removes one such "other consideration" that I allude to in the above paragraph.  If they were sent unencrypted, then the proper action would to make these randomly generated password be one-time-use passwords which must be reset once you gain access to the account.  This way, if someone did beat you to logging in, you would know, and could take additional action as necessary.

Another consideration is password storage.  Since you have access to the application's source code, you can ensure that they're using a key stretching algorithm with configurable difficulties to make offline brute force attacks as expensive as possible. The NIST standard specifically mentions PBKDF2 and BALLOON.  Other key stretching algorithms with configurable difficulties include bcrypt, scrypt, and Argon2.  Simply salting and hashing a password is no longer considered secure, even if using the "best" cryptographic hashing algorithm. These hashing algorithms are indeed part of PBKDF2, but should not be used by themselves to secure passwords.

One final consideration is the human factor.  People don't enjoy using very long, truly random passwords. The longer and less memorable it is, the more likely it is to appear on sticky notes tucked under keyboards.  The solution to this, of course, is to encourage use of password managers.


Lots of TLSCiphertext length MUST NOT exceed 2^14 + 2048 in wireshark

This looks like a wrong interpretation of the data. What most likely happened is that some TCP segments got out of order or lost, confusing the TLS dissector in Wireshark. This seems to be supported by your observation of retransmitted packets.

Some applications also do not align the start of a TLS records with the begin of a TCP segment when a lot of data is being pushed, filling up a full TLS record.

When Wireshark loses track of the start of a TLS record, it will guess that the start of a TCP segment coincides with the start of a TLS record. Clearly that will not work if the previous case applies. If you right-click on the packet and use Follow Stream -> TCP stream, you'll most likely see some "Ignored Unknown Record".

Assuming you have have captured all packets, you can fix out-of-order TCP segments handling by enabling a TCP preference, see https://wiki.wireshark.org/TLS#Preference_Settings

As for the expert info on exceeding the record size, that was added to help catching implementation bugs where a too large record was sent. In your case it is bogus. See these commits:

https://gitlab.com/wireshark/wireshark/commit/ff0371e898
https://gitlab.com/wireshark/wireshark/commit/bb1450b017


Microsoft Windows Defender keeps detecting BrowserModifier:Win32/SupTab!blnk

I found similar issues on these MS forums pages:

https://answers.microsoft.com/en-us/protect/forum/protect_defender-protect_scanning/windows-defender-keeps-saying-harmful-software/25532dc1-2ca7-402b-8a91-2be7c44fd65a

https://answers.microsoft.com/en-us/protect/forum/protect_defender-protect_scanning/i-can-remove-browser-modifier-win32subtabblnk/49bbb618-d919-4269-a6c8-784a0953396b

A program named VulcanRT seems to be a common denominator in both - could it be you have something similar?

Some tips I found in the above sources that might be useful:

Check browser add-ons/extensions that might be causing the issue
Try resetting your browser/s
After cleaning up with Windows Defender, clean Temp files and reset the computer

Here's what somebody who managed to clean it up had to say:

  In the end this is what I did :

  I did run the programs listed in the link above, and I did reset Internet Explorer.  Restarted after each step.  Even after resetting IE, once it was opened the warning came back.

  Roguekiller was the one program that found anything, deleted what it found.

  At that time WD came up with a new link in its warning for this which led to a folder/program that I could uninstall (VulcanRT), I can reinstall it later if need be though I think my graphics will be fine without it.  Uninstall successful.
  I also uninstalled Google Chrome completely.

  Ran Revo Uninstaller Pro, looked for anything installed in the last few hours before the issue started.  There were two redistributable files, uninstalled both of them.  Uninstall successful.

  Uninstalled a game that I had installed through Steam (which I  have never have problems with installs from but did this anyway).

  Restarted after each of these steps and kept IE closed during everything.

  Not sure which of the above steps did the trick but I have now had IE open for awhile and the warning has not come back up.

Here's a joyful update from reddit:

  I have fixed the problem.

  I went to the directories shown in Window Defender and manually deleted the shortcut .lnk files. For me they were Google Chrome and Internet Explorer. In File Explorer they were .exe files instead, deleting these remove the applications from the Start Menu. Well I can live without it.

  It does look like a false positive to me. A system restore I performed did not fix it. Note that I restored it to an earlier point in time before the notifications started showing.

Hope this helps!

If it doesn't, some Google-fu might lead you to the right answer - as you said, there are a lot of results so you can just go over them :)


How to secure embedded code containing REST api call

You can have something like a JWT token, where the user (front-end) will know, but can't read it. Then, for each request you send the JWT token and your back-end will know how to decrypt and validate if the user can perform or not this action.


mod_security sent the user a HTTP 403 response, which means (quoted from RFC 2616):

  The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

The reason for this block is it matched the pattern "uname -a" which is a unix command for returning system information. Here is an example output of such command:

  Linux k4rrax 2.6.35-32-generic #64-Ubuntu SMP Mon Jan 2 23:31:33 UTC 2012 i686 GNU/Linux

This "attack" is probably just a random scriptkiddie or bot trying to see if it can exploit you in any way. It is very commonly seen on the internet. The origin IP adress is already blacklisted several places: https://www.google.com/?q=200.158.8.207


Openssl ciphers: what does Au=ECDH mean?

Taken from RFC4492 Section 2.1

  2.1.  ECDH_ECDSA

  In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public
     key and be signed with ECDSA.

  A ServerKeyExchange MUST NOT be sent (the server's certificate contains all
     the necessary keying information required by the client to arrive at the
     premaster secret).

  The client generates an ECDH key pair on the same curve as the server's
     long-term public key and sends its public key in the ClientKeyExchange
     message (except when using client authentication algorithm ECDSA_fixed_ECDH or
     RSA_fixed_ECDH, in which case the modifications from Section 3.2 or Section
     3.3 apply).

So in this case the server's provides a DSA certificate containing an ECDH capable public key that's signed with ECDSA.  So to answer your first question, the server must be signed with ECDSA.  The authentication (Au) for the key exchange is still verified with ECDSA.  I could be wrong, but I think this might just be an error in OpenSSL's parsing.


Assemble P12 from local cert and HSM private key pointer?

Highly doubt PKCS#12 supports that.

How do you expect the 'pointer' to behave? Some UUID that's recognized as existing on external HSM, and also identifying the HSM where it exists?


Is there a way to clone Mifare DESfire EV1 key sent by a NFC reader?

The key is not sent by the reader. A challenge-reponse protocol is used for the reader to prove to the card it holds the key. To attack this over the air you would need to break the underlying algorithm - which makes this question "how secure is Triple-DES / AES.

If you are asking about attacking the reader directly then yes the reader has to store the key. These are usually programmable - so with access to that interface you may be able to lift the key. But this is going to be highly reader and key distribution method dependent.

It is also worth noting the cards support per-application keys. A well designed system would segregate functionality so if a single application had keys compromised others would still remain secure. For example for a canteen system you could have different keys for topping up the card and spending the balance. If the cafeteria tills card readers became compromised it would still not be possible to add false balance - only to withdraw it.


Can I safely use a physical USB stick inside VirtualBox (isolated) without possibly infecting the host OS?

Short answer: No.

When you use VirtualBox, the USB device first connects to the host. Only then, through the VirtualBox drivers, the device is made available to the guests. This part cannot be circumvented because VirtualBox uses the Host OS capabilities for the most part (i.e., it is not a bare-metal hypervisor).

Most often, if there is a supported file system on the USB device, it is also auto-mounted, giving rise to further security issues. This part alone can be prevented in most OSes (by disabling automount). So if the malware depends on filesystem / file-related actions on the OS, VirtualBox could isolate the malware on the Guest OS (unless the malware uses VirtualBox-specific exploit to escape the VM and access the Host OS).


How to optimize cracking speed with Reaver

The WPS PIN vulnerability is an online brute-force attack: you make a guess at the PIN, and the router tells you if it's correct or not.  Because of this, the limiting factor for attack speed is how fast the router is willing to talk to you.

You can speed things up slightly by using small DH values to reduce the amount of computation the router needs to perform, and by reducing how long you wait between guesses, but if the router is rate-limiting you, there's not much you can do.


Is a redirect showing the password in plain text a security vulnerability?

Definitely problematic - and worth reporting.

If the HTTPS is properly protected with HSTS and preloading, then threat actors observing the traffic wouldn't be able to see the GET contents. But since HSTS is still somewhat rare (and if they're putting plaintext passwords in a GET, they're probably not aware of other best practices like HSTS), the interception/downgrade risk is probably somewhat high.

Separate from that, regardless of the health of the HTTPS setup, remote HTTP servers almost always log full GET contents in the server's logs - so those plaintext passwords are probably being recorded on the server as well.

[Edit: and vakus' answer covers the rest of the attack vectors much more thoroughly!]


OSPFv3 uses IPSec if you don't know much about IPSec I wrote a paragraph about it in another answer which should give you some more information.
In Ciscos implementation of OSPFv3 they use MD5 correct, however, it's not to keep the data safe, it's merely used as an authentication check. You can read more about OSPFv3 in Configuring IPSec. IPSec is pretty secure I don't think you have any reason to feel that it's not, for confidentiality of data you can use AES-CBC 128/192 but more is in the link I provided.
I believe Cisco's implementation has thrown you off a bit as you've seen MD5 and instantly assumed "bad" however that's not the case, they're not encrypting the data with it else that would be bad.

Regarding people "tampering with the routing tables" I find this section to be a little unclear. If you're worried about local credentials on newer Cisco devices/versions for local credentials, you can use Type-8 passwords, you can read more about this here

Just to add to this Forest's comment on it being used as an HMAC is correct.


With plain FTP the credentials are passed in plain and thus can be easily sniffed. Also, the files are not only send in plain but they are also not protected against modifications, i.e. an active man in the middle might change the files on the fly. Insofar the risks are similar to plain HTTP, i.e. it might be fine within a trusted network but is a bad idea if you cannot fully trust the network.


If you hope to keep the private keys out of the hands of whoever runs your program, then it will not work. Secrets embedded in code do not resist reverse engineering (especially when using Java, which is quite easy to reverse-engineer).

Though you do not give any detail about your situation (you just say "Java" and "the program"), I can give the following generic advice: arrange for your private key to be user-specific, and such that it is the user's best interest that the private key remains private. In that case, the user will collaborate to the key security. You may then store the private key (or a password which unlocks the private key) in the Java preferences.


Who is this strangely named Certificate Authority?

This looks like a poorly encoded name which was even more poorly decoded and reencoded.

Initially, the name seems to be: A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH

The name was then encoded in big-endian UTF-16. In this case, this means that every character yielded two bytes, the first of which having value 0.

Upon decoding, whatever did the decoding failed to recognize the string as UTF-16 (maybe it was wrongly tagged in the certificate; an UTF-16 string should be BMPString but some cases of UTF-16 stuffed in TeletexString have been spotted in the wild; see the X.509 style guide for more about it). The string was decoded as if it was ASCII, with "invalid" bytes represented with the C-style convention of "\x" followed by two hexadecimal characters. This sequence is used in the C programming language to insert explicit byte values in literal strings. Therefore, the initial "A-T" became "\x00A\x00-\x00T". Similarly, "für" became "\x00f\x00\xFC\x00\xr" because "ü" is not an ASCII character, and has value 0xFC (aka 252) in Unicode.

When printing out the string, a further injury was inflicted on that string, namely the wholesale removal of all backslash characters. This yielded the exact string that you observe.

(Note that the EFF "CA map" shows other examples of this "C-style without backslashes" representation, e.g. "SCEE - Sistema de CertificaxE7xE3o ElectrxF3nica do Estado", which really should be "SCEE - Sistema de Certificação Electrónica do Estado".)

Now a simple Googling points to, indeed, a commercial German CA called A-Trust. Now the mystery deepens a bit, because the CA Web site uses a certificate issued by the CA itself, and the root CA uses the name: A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, which is correctly encoded in the certificate (as an UTF8String), but is not exactly the one you observe: the "für" has been replaced with "f.".

My guess is that what you see is a previous version of the root CA certificate from that CA, and it had encoding problems, which were "solved" by changing the text into something which is pure ASCII. I.e., instead of fixing their software to handle non-ASCII characters properly, they sidestepped the issue. That's kind of sloppy.


Accessing user accounts without asking for their password

Firstly as per @EricG most of the administration should be handled using a network administrator account, using group policies and the like.

If you need access to a users logged-in session the best way to approach this is to have the user login to their machine and then hand you the keyboard. That way you never learn there password, and the user can observe the steps you take. As noted in the comments this can also be done by various remote support, screen and session sharing applications.


Is there a way to guess a shared server's control panel's version?

Kinda.
There is no format of displaying version number that all control panels use and so each control panel displays the version their own unique way.

If you want to find the version for a specific control panel I suggest you do the following:

Try looking the source code, the corners of the UI, headers in the requests or even google "How to find out what version X is running?" and see if there is anything relevant there.
Look for unique actions of the control panel and compare it to the versions update log (Assuming there is one on the control panel website) to find similar actions.
Set up a script that is able to identify a version of a control panel based on unique identifiers per each version and run it to check a specific site.


Secure RESTful api communication between multiple servers

Because you are mainly concerned with the security of your program (i.e preventing someone from issuing commands to your clients), you also have to identify your threat model. For example, if you are sending commands to a program to unlock your front door, your approach in designing the application becomes much different than if you are just sending meaningless data such as "hello world!".

Once you have defined that, you can make decisions on whether you should hash a password in your database and lock the key in a safe or a plain text password might work for insignificant data. I will try to speak to your application though without knowing every single detail.

You are already using SSL/TLS so that's a great start. You have implemented a form of authentication, a way for the clients to prove to the server that they are legit. You have physical control over the hosts, so I assume no one can get physical access. If you have static IP's, sure, throw a whitelist in and a possible firewall to restrict certain http methods (GET,POST). You might consider a front end proxy such as Nginx to do all this on the server. I would highly suggest you do not allow the clients clean cut connection to the database. Only allow the server to make connections to the database. You mention you are storing passwords in the database, why not hash/salt them? Again, depends on your threat model.

You mention that the client machines are under your physical access but could be stolen. If a attacker has physical access to a box, all bets are off. Your best bet here would be identifying as quickly as possible that a client is compromised. You are already using tokens, why not have a expiry time

Lastly, any data sent from the clients to your server must, must, must be sanitized and checked. If you have a idea of what the data looks like, set a template and any data received that does not match it, reject it


Tutorials, Exercises and Environemnts for Penetration Testing Mobile Environments

Smart phones are not that different from laptops, so building your own mobile lab and attacking the targets there is a good approach.

Hosting your target:

Use an Android emulator to host your Android target. You can interact with it from the command-line via ADB
iOS has the same thing but they call it the iOS Simulator
Or you can use physical phones but root or jailbreak them for better low level control.

Network setup should contain the minimum:

A router with flexible controls. dd-wrt works on your wireless router or a Linux (virtual) machine. A wireless router is preferred.
A computer with a packet injection card to perform wireless attacks on your physical phones. The best choice seems to be the Alfa AWUS036H card from Alfa Networks as BackTrack supports this out-of-thebox.
A Backtrack (or similar) installation because it contains most of the wireless attack tools.

Intercept and modify SSL/TLS phone communication steps:

Generate a Certification Authority (CA) SSL certificate
Install that certificate in your phone certificate store for Android and iPhone
Setup your phone to use a proxy on a computer where you
Install an interception proxy (ZAP, Burp) to intercept the phone traffic. Install the CA certificate on that proxy. Note that ZAP will generate a CA certificate for you.
Access an SSL website or use an app that uses SSL and see the traffic in the interception proxy. You can trap the HTTP requests in any direction and modify them. This way you can test the security of the app or the server application.

You now have a working mobile pentesting lab.

Download and install vulnerable versions of Android then test public exploits from exploit-db.com http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=Android

This is a list of presentations and whitepapers I have collected and used for pentesting Android. You can use this list to extract attacks and try them in your lab environment:

A Brief Guide to Android Security
A framework for on-device privilege escalation exploit execution on Android
A Framework for Static Detection of Privacy Leaks in Android Applications
A Local Cross-Site Scripting Attack against Android Phones
A Methodology for Empirical Analysis of Permission-Based Security Models and its Application to Android
A Study of Android Application Security Slideshow
A Study of Android Application Security Whitepaper
A Study of Android Permissions and How Applications Use Them
All Your Droid Are Belong To Us: A Survey of Current Android Attacks
An Android Security Case Study with Bauhaus
Analyzing and Dissecting Android Applications for Security defects and Vulnerabilities
Analyzing Inter-Application Communication in Android
Android application security, the fun details
Android Browser Cross-Application Scripting
Attacks on WebView in the Android System
Enhancing Security of Linux-based Android Devices
Exploratory Android Surgery Paper
Exploratory Android Surgery Slides
Fuzzing the Phone in your Phone Paper
Fuzzing the Phone in your Phone Slides
How smart is your android smartphone?
Paranoid Android: Zero-Day Protection for Smartphones Using the Cloud
Penetration Testing Android Applications
Penetration Testing of Android-based Smartphones
Policy Oriented Secure Content Handling in Android
Privilege Escalation Attacks on Android
Securely deploying Android devices
Security Issues in Android Custom ROMs
Systematic Detection of Capability Leaks in Stock Android Smartphones
Taming the Robot: Sandboxing Android
TEAM JOCH vs. Android
The Quest for Security against Privilege Escalation Attacks on Android
These aren't the permissions you're looking for
Towards Taming Privilege-Escalation Attacks on Android
VMM Based Rootkit Detection on Android
Yet Another Android Rootkit


Token authentication and storage / websocket issues

To store the token:

For a traditional (non-Ajax) web app you usually store the token in a hidden form field.
For a single page app you usually store the token in a JavaScript variable and include it in the JSON data with each request.

This approach avoids the token being in the URL, and it works with WebSockets.

Most applications use a cookie as the main session ID, and have a second token which is purely to prevent CSRF. You can ditch the cookie and solely use the token, as you suggest, but doing this is not standard practice, so you should only do it if you're sure you know what you're doing.

As you mention, cookies have an HttpOnly option that is not possible with tokens. Although tokens don't have a secure flag as such, that is less important, as you can adjust your code so the token is only ever sent over SSL.

One other thing to be aware of is you can now prevent CSRF without using tokens, primarily using the origin header. However, most sites still use tokens.

You can do normal cookie authentication with WebSockets. This question has some information. I don't know what the CSRF implications of this are.


Saying that only critical applications need HTTPS is like saying that only those e-mails containing actual secrets need to remain private.

Privacy on the Internet is a bigger picture. If most of the websites you're visiting use HTTPS, it will be significantly more difficult for an eavesdropper to synthesize a profile of you and your habits. Also, the fact that you don't consider a particular website security-relevant might not apply to someone else. Someone in an oppressive regime might be at risk just for researching a particular news topic and will benefit from any news blog that serves its content over TLS.

Privacy aside, every download over HTTP gives a man-in-the-middle the opportunity to inject their own malicious content. A seemingly harmless download of a Word or PDF document could be silently replaced by malware. Then it won't matter that you downloaded it from a small site that seemed too unimportant to use HTTPS.

Especially with free certificate providers like Let's Encrypt, rolling out HTTPS even on small websites should be a no-brainer. You're contributing to a safer Internet where encryption hopefully soon becomes the norm.


How to protect my computer from being tracked by a web site?

can't see that I visited it

You can prevent an owner knowing the you personally visited. To do so, you need to mask your originating location. Either via something like TOR or via a VPN than changes you address on each request. You also need to mask your browser signature since that may also be used to track you. Using Incognito/InPrivate sessions, refusing cookies and other local storage and changing parameters such as local IP address, screen size, etc. - or alternatively keeping them static but at the most common possible values so that you cannot be detected from everyone else.

You cannot, of course, prevent them from knowing that someone visited.


The x86-compatible CPU are aptly named: they are compatible with each other. This means that the same OS code will work on all of them. So, from the point of view of the code which runs on the processor (which includes the operating system itself), things do not vary (much) depending on the brand. Things change depending on the generation: the newer systems have the NX bit while older systems must rely on tricks with segment registers or complicated TLB/cache dances (see this answer for details).

The core concept is the same for all modern CPU: address space is split into fixed-size pages (or, if different page sizes are supported, their lengths are all multiple of a given atomic length, normally 4 or 8 kB). Access rights are enforced at a page granularity: a whole page is readable and/or writable and/or executable.

Hardware-wise, details on the implementation of the MMU can vary quite a lot, but within a rather generic framework: access rights for each page are stored in tables (the address of a master table being recorded in a specific CPU register) and cached in a dedicated structure (the TLB) for faster access. Upon every memory access, the rights for the target page are loaded from the TLB (the TLB being filled from RAM if necessary) and compared with the access type. The CPU is well aware of what kind of memory access it is doing (whether it is code execution or data read or data write). The lack of hardware support for DEP in older x86 MMU is an omission from the Intel designers of that time (circa 1982 for the 80386); it probably saved a layer of transistors somewhere. The venerable 68000 from 1979 did not include a MMU but was smart enough to advertise the access type on its connectors for each access, and it did distinguish code execution from data reads.

On ARM CPU, the same concepts are in force (it is still page-wise access rights) but the MMU table format is different from that of the x86.


What is the impact and threat of Spectre in Javascript?

That is an incorrect assumption. Right from the Meltdown/Spectre website:

Spectre breaks the isolation between different applications. It allows
an attacker to trick error-free programs, which follow best practices,
into leaking their secrets.

A vulnerability in the CPU architecture (this is not a browser vulnerability) is not aware of or limited by arbitrary boundaries such as site isolation, as it is at a much lower level. Memory of other processes can be read, or even from the kernel. It is a major violation of the process isolation-based security model that many things rely on.
For more information, I recommend reading the above linked website, and the research paper. There are also plenty of ELI5 posts out there if that's too deep.


What is the impact of an exposed secret key for a JWT token implementation?

Whoever possesses the private key can create valid tokens where your system simply can not distinguish between a legitimate token and a token created by the attacker.
I am guessing you are not just using the expiry field but also the subject field sub, which is in short terms the logged in user.
With the private key, I can create a token with any subject I want, thus sign in as any user of your system.
As you stated, I can also add any other claim and you system has no choice but trust it, as I was able to create a valid signature.
It can not be stressed enough, but JWT heavily relies on the private key to stay absolutely private. Losing the private key is the worst case scenario.


I will assume the devices will transmit tuples (serial, counter, key, value) where:

serial: an unique id for the device (ideally set at the factory).
counter: a keeps track of the number of messages sent to the central server
key: name of the parameter you are sending
value: the number

Make the devices encrypt that big message with the public key of the center (if you can afford also having a private key per device, add a digital signature, too. Otherwise, use a fixed part on the serial id field that was generated at random and is not known to third parties).

The plant server only ever sees encrypted messages, so he can't modify them. It could choose to miss some messages, but you would notice the gap in the counter. Or that a given device stopped sending data two weeks ago.

Note that we go from "securing data on three places" to just "secure between device and center". Of course, there's no reason the plant server couldn't additionally use https when connecting with the central server, but that wouldn't be necessary for the confidentiality of the messages themselves.

You talk about "SHA key", which doesn't make much sense (SHA is used for message digests…). Simply use asymmetric cryptography. Your devices can probably use elliptic curve crypto.

You still need to get the other bits right, like using an authenticated encryption mode (eg. GCM) or else performing additionally checks, an attacker that compromised the whole device, could impersonate that device (but only that). The central server should check that things make sense... but otherwise this should provide a good basis to start.


In IDS in the classical sense is passive (D for detection) and can not drop a packet. In IPS instead (P for prevention) can drop the packet and better should do it. But the usage of the words IDS, IPS, firewall etc is too vague today that it is not clear which kind of technique you are talking about.


How Can Someone Do A Denial Of Service Attack With JavaScript

It works because it's a distributed denial of service attack, not just a denial of service attack. You sneak that code snippet into a lot of webpages that a lot of people visit (e.g. by including it inside a library that does something useful that other developers will pick up and use). From the article:

  In September 2014, RiskIQ reported that jQuery.com’s website was
  compromised, which hosts a very popular JavaScript library that could
  have easily been replaced with a malicious one. The threat of
  attackers injecting malicious JavaScript into millions of sites is no
  longer theoretical.

A lot of websites out there use jQuery or other libraries by including remote javascript source files (instead of making local copies of them; by using the remote version your web page may load a tiny bit faster for your users, and of course you get new features and bug/security fixes "for free"). If the javascript source files were compromised, every website out there that included them would be serving the compromised versions to their visitors, so every one of their users would be participating in the DDoS.

The DDoS itself just works by overloading the target web server with requests. Imagine you're working at a fast food restaurant: if one person comes in and orders dinner, you can handle that. If the entire city suddenly shows up and starts shouting their orders at you, you'll be too overwhelmed to fulfill even one order let alone all of them.


Sending access token through GET request

As explained here, sensitive data in the URL query part (such as a secret API token) is primarily an issue if the URL is accessed directly in the browser and therefore visible in the URL bar as well as stored in the browser history.
But API requests are usually performed in the background of an app or via a background AJAX request and therefore you're much less likely to run into a situation where the plain API request URL is presented to a user. Therefore the dangers of sensitive data in the URL are negligible for an API.
Also note that over HTTPS the full HTTP request is encrypted, including the query part. Only the hostname (api.instagram.com) would be exposed to a MITM as a side effect of SNI.


Multicast DNS is a protocol which is used by devices on the network announce to the rest of the local network that they are there (name) and what services they offer to others (printing, audio...). It is not really a connection but a broadcast, i.e. the information are send to a special multicast address and all devices on the local network will listen for information on this address.

Sure, it makes it easier to discover for an intruder in the local network what else is there, since it was explicitly designed for providing this kind of information (i.e. use devices and services without much explicit configuration). It can also be used by an intruder to announce itself as some service in the hope that others will connect to it. But it can not really be used to spread malware by itself - unless the recipients mDNS stack is broken.

Thus while there were (of course) bugs in the related network stacks in the past and might also be there currently, it is no more dangerous than any other network protocols you use, probably even less since it should be restricted to the local network. In other words: there are probably more serious problems in your network you should worry about.


Does a RAM Disk Actually Help When Password Cracking a Small Hash

Most likely not.

Password cracking is a computationally-bounded operation. Modern SSD and hard disks can read way beyond the number of hashes you can do with current CPU/GPU.

Additionally, all modern operating systems will do read ahead buffer and file caches automatically, so most of the time you'd be reading from RAM already.

I once ran john-the-ripper with a large piped word list like so with apr1 hashes:

pv wordlist.txt | john-the-ripper --pipes --rules hashes.txt

pv is a tool similar to cat, but it can calculate and show you the speed of data going through your pipe. Most of the time, you'll notice that the pipe is stalled.

If you used a fast hash and you have a cracking cluster with very large computational power, then the speed of reading the file could possibly affect the cracking speed more, but it's quite unlikely that the speed of the disk would be your first bottleneck.


Is it possible to add backdoor to a file with the same size and crc32 checksum (4bytes)?

Yes. CRC-32 does not prevent deliberately creating a file with the same CRC-32 and size as another but with different contents. For that, you need a cryptographic hash, such as SHA-256.


What are ways I can analyze malware in an infected machine, not just clean it?

Malware analysis should be done in a VM preferably disconnected from the Internet.  This is mainly to protect your system, and stop it from spreading (if the malware has that capability).  You can also use snapshots, or sometimes you can setup a VM to never keep state.  VirtualBox is free and will do the job.  VMWare Player is also free, but limited.  Doesn't allow the use of Snapshots unfortunately.

There are various tools out there to help you with malware analysis.  Being disconnected from the Internet can sometimes stop the malware from executing its malicious code.  There are a couple of sandboxing tools that will listen on ports, and respond to network requests appropriately in order to coerce the malware into continuing its operation.  The one recommended by Practical Malware Analysis is FakeNet.  With FakeNet you can even design custom responses to proprietary protocols, and/or non-standard ports.

Cuckoo Sandbox is an open source tool that can provide analysis reports on the malware during its operation.  It can track system calls, keep copies of files created (even if they're later deleted) by the malware, and give memory dumps of the entire system.  A very powerful tool.

Most malware is packed so you'll want to make sure that you can unpack binaries, extract resources, etc.  UPX is the most common.  CFF Explorer is pretty handy for analyzing resources, and includes a UPX utility.  You might want to checkout these 5 tools recommended by MAMB.

These tools will give you a great look at what the malware is doing on a system.  However, if you need to get down to the gritty details you'll want your ever popular IDA Pro.  This is mainly for more complicated malware that you can't coerce into running.  Some malware will start up in suspended threads to run later.  Some just know that you're not connected to the Internet via their own checks.  So you'll have to depend on the disassembly for figuring out what they're trying to accomplish.

Other tools that are helpful, debuggers.  Windbg or Ollydbg are the two most common, but there are lots of options.  Allows you to attach to the piece of malware while its running, set breakpoints, inspect memory, etc.