I didn't wipe my hard drive before I sold it. How would a criminal take advantage? I just sold a Mac Mini, and I erased/formatted the hard drive before I turned it over, but I didn't wipe it securely (not wise, I know). How would a criminal take advantage of this fact? What is the probability of any of my sensitive files (passwords) being compromised after the buyer reinstalls the operating system?

This computer was not used for a lot, but I did use it to work from home and it may contain passwords for work-related things.

My suggestion would be to change your work (and possibly other) passwords, just to be on the safe side.

It is quite easy to retrieve data, even after a format, with the proper tools. A quick Google search on "data recovery tools" reveal that a lot of (paid) tools are available to recovery data.

In my personal experience it was possible to retrieve data from a machine that was formatted during a new Windows installation. Even after the OS was re-installed I was able to get back all of the "lost" data.

Although the likelihood of someone doing this is low, you shouldn't take any chances on your passwords. At this point I do consider them compromised.


How to scan USB drive with clamav on Linux Is there a way to scan the entire drive including auto-run and all partitions, including the master boot record (MBR)?

In Linux anything is a file. That includes your devices' MBR.
All you need to do is simply preform a scan on the associated
device driver file.

To find this do the following in your terminal:

mount | grep -e (media|mnt)

This will search your mounted devices for anything
in /media or /mnt. Typical distros use /media/, you should
know your location just by browsing to the root of the device.

Next you should see from the output of mount something like the
following:

/dev/sdb1 on /media/sdb1 type ext3 (rw)

The device /dev/sdb1 is the second device(b), first partition(1)
after the MBR/GUID table. Thus your device file you want to scan
is /dev/sdb and you would scan with

sudo clamscan -i /dev/sdb

Make sure you do regular backups with tar(1) and/or dd(1) as well


What can be tracked by my boss if I am logged into my work Gmail but using private Wi-Fi at home Basically, I had the Gmail app on my personal mobile. I was on Google doing a search about coming out as gay and I had only searched on Google, not clicked on any pages yet.

I noticed at the bottom of the page that Google had logged me into the Safari app. I was at home on my own Wi-Fi so other than being logged on to my Gmail account, there was no connection to work.

I have now left that employment under bad circumstances and my dad has decided to represent me in a court case.

I am now panicking that my boss can look back and see this/has already seen this and will use it as ammo if it gets to court just to be spiteful.

I am nowhere near ready for this to come out so I am just wondering if they can really see what I do on my personal device on my private Wi-Fi if I was logged into a work Gmail.

If the Google account you were logged in as is now under the control of your boss (as per this question), he can go to his search history page and see all terms that were searched for under that account.

That said, I suspect he probably isn't aware of this, so I wouldn't worry too much. It's a lesser-known feature of Google, and it probably wouldn't occur to him to check it out anyway. I should also point out that, in the unlikely eventuality that he does discover your search history, any attempt to blackmail or leverage you would be a very serious crime in almost any country. You'll likely find that you're protected by anti-discrimination laws, privacy laws, human rights laws, employment law, and a whole range of other legislation at the state, national, and international level.

On a more personal note, I recommend looking up LGBQT charities and advice groups in your area (on a private browsing tab, if you wish) to see if they can provide you with guidance and support in relation to your situation. Stonewall is the biggest advice group in the UK, and It Gets Better is a major US organisation with similar services and goals. They have experience with employment issues, discrimination cases, and the difficulties people face in coming out - they may be able to help put your mind at ease about what you're going through.

Best of luck and I hope it all works out.


How much safer is it to use the command line in Windows Server 2012? In regards to Windows Server 2012 how much less risk is there for a system to become compromised if the admin is done trough the command line and not Server Core / MSI or the full GUI?

So in essence how many exploits of WS 2012 has something to do with the GUI?

The purpose behind the "Server Core" was to bring it in line with Linux/Unix.

Linux servers do not have a GUI, unless one is installed. Because this has been the default, one isn't expected, and administrators have worked that way for decades.

Windows Server has had a GUI, since it's birth. This has been an attractive feature for those who have previously administrated/worked on Windows Systems. You click buttons, and things happen. There isn't a whole lot of thinking involved. Even when installing "server roles", you get a tutorial along with it.

Some have said (including Microsoft) that "server core" is more secure. This seems to be exaggerated. Sure an attacker has less opportunities because of the lack of GUI (double extension files and the likes), and the processes required to run it, but on the remote side of things, nothing has really changed. The command line is the same as in previous versions, and critical processes still run.

The things removed include:

The Windows Explorer desktop shell (Explorer.exe) and any supporting features such as Themes
All MMC consoles
All Control Panel utilities, with the exception of Regional And Language Options (Intl.cpl) and Date And Time (Timedate.cpl)
All Hypertext Markup Language (HTML) rendering engines, including Internet Explorer and HTML Help
Windows Mail
Windows Media Player
Most accessories such as Paint, Calculator, and Wordpad

Funny enough, you are still running GUI programs, it's just a case of invoking them from the command prompt, rather then the start menu or other such cases. Notepad is stripped down but still retains it's functionality, and you can still remotely connect to the machine and get all the MMC console functionality back.

To claim "70% of the vulnerabilities in the last 5 years" being resolved either shows how sloppy the GUI was done, or how many unneeded features are included in Windows Server and inadvertently allows generic Windows malware to infect the server OS branch.

The major benefit of Server Core is that because of the limited GUI, it has a lighter memory footprint as well as on other resources. Do not expect a huge increase in security as many would like to claim.

https://channel9.msdn.com/blogs/duncanma/iain-mcdonald-and-andrew-mason-show-off-the-new-windows-server-os

https://www.petri.com/understanding-windows-server-2008-server-core

https://msdn.microsoft.com/en-us/library/dd184075.aspx


How do you protect against your IT domain admins accessing your data? I work at a small company and we use an external company to take care of all our IT needs (a "managed IT service provider"). This includes managing our windows domain, our network, and everything else. To do so, they obviously have domain admin rights over all the computers.

Some high-profile employees work with sensitive files and data that we need to be sure no one is able to access or steal.

How can we set up our security so that no one in the IT department is able to access what they should not? Is there a way to guarantee this? Or is it required for the IT admins to be trusted?

In other words, if IT administers our firewall and accounts and security, how can we"police" the police?

What you're asking is not simple. It ranges from very difficult to impossible.

Your company has outsourced the highest privilege level in its environment, and now it wants to prevent those highly privileged individuals from doing something.

They can disable or manipulate any of the native Windows tools. Bitlocker, EFS, etc cannot help you if they have configured GPOs to deploy recovery agent certificates or to backup recovery keys into AD.

They can perform remote monitoring sessions or deploy monitoring/keylogging applications if they want. It takes less than five minutes to setup a software deployment policy if you know what you're doing. You could use non-Microsoft solutions, but those accomplish little if they are running on untrusted systems.

Compartmentalize... if you can.

The problem with compartmentalization is that it's all or nothing. If your email and office apps run on domain systems, it probably won't work.

All of that super important and sensitive data needs to be analyzed, shared, discussed, tasked out, and managed. It will make its way into specifications, project plans, emails, and executive summaries.

If you run unmanaged systems to compartmentalize, you cannot introduce that compartmented data back onto centrally managed machines. This will make some normal business tasks very burdensome. You can run a second, isolated domain to facilitate this---but that is likely more work and expense than simply running everything in-house in the first place.

Accept the risk, or retake control.

In the end, you'll have to make a choice.

You can accept that these contractors have access to sensitive data because they have ultimate control over the systems that process it. Or, you can bring the management roles back in-house, and then you can vet/monitor your admins as you see fit.

Depending on the cost involved, management may simply accept the risk. If there are underlying legal or contractual requirements to protect that data, then maybe the hassle of compartmentalization is worth it.


oAuth2 scopes and filter conditions in url I have an api like /v1/api/data and two clients, client_unrestricted and client_restricted.

The api itself is protected by Oauth. I want to ideally register the clients with the OauthServer so when client_unrestricted makes a requests it gets to see all the data . client_restricted makes a requests it gets to see only subset of the data

Should i ask the OAuth admin to register the clients so the endpoints are like this

client                      endpoint
client_unrestricted         /v1/api/data/{data-ids}?restricted=false
client_restricted           /v1/api/data/{data-ids}?restricted=true
Or can OAuth Scopes help me here where i register only one endpoint /v1/api/data but vary the scopes for both the clients ?

client                      endpoint                            Scope
client_unrestricted         /v1/api/data                        restricted=false
client_restricted           /v1/api/data                        restricted=true

In Oauth2, you restrict the redirect_uri that can handle the login request the user is sent to after logging in at the authorization server (AS).

So you would register two clients with the OAuth2 admin, each with its own redirect_uri.  But this is a defense against someone stealing the authorization code as it is passed from the client to the API.

Restricting the data each client is server, is handled by using scopes, as you suggest.  I is usually best to have distinct API resources that serve the different types (restricted/unrestricted) data, and only give the unrestricted client the scope necessary to consume the unrestricted API.

Something like this:

/v1/api/basicdata - available with a "basic_data" scope which both clients get.
/v1/api/restricteddata - available with a "restricted" scope.


Should I be concerned if my employer is performing man-in-the-middle HTTPS attacks? I have reason to believe that my employer may be performing HTTPS man-in-the-middle attacks on company-issued work laptops, as Java's SSL Certificate lists my employer as the Certificate Authority.

When launched, the Java Platform (jp2launcher.exe) displays a warning that the connection to https://javadl-esd-secure.oracle.com:443 is untrusted, and that "The certificate is not valid and cannot be used to verify the identity of this website."

Clicking More Information opens a window stating that "The digital signature for this application was generated with a certificate from a trusted certificate authority, but we are unable to ensure that it was not revoked by that authority." A link to the Java help page for self-signed certificates is also included.

I cannot share the full certificate details, as doing so would reveal the identity of my employer. However, I can confirm that Java lists my employer as the Certificate Authority.

Is my employer running man-in-the-middle HTTPS attacks? If so, should I be concerned about potential security exploits?

I've read that HTTPS scanning can lead to weakened browser security, such as when Kaspersky exposed users to MITM attacks earlier this year. If company-run HTTPS scanning is common practice, couldn't it fall victim to the same previously mentioned security issues?

As promised, here is a copy&paste of my answer to your previous question.

Ok, you've found your company's CA cert in your java trust store. That tells us that they have the ability to perform the MitM attack that you are describing, but it does not prove that they are actually doing it. That cert may be there for a completely legitimate reason, like for example so your VPN client can authenticate the VPN server, or so you don't get certificate errors when connecting to internal network resources. As @schroeder says, this is completely normal behaviour for companies that issue laptops or have BYOD policies. In this case, it seems like they installed the certificate so they they can code-sign their java applets. It also sounds like they did a bad job of setting up their CA since they have not provided revocation information for the certs. There is nothing in your question to indicate that they are doing any HTTPS interception.

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

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


(Public) IP address [x.x.x.x] of Synology has been blocked by SSH For the past few months I regularly see alerts on my Synology about SSH connection being blocked. Somebody (here a nice Chinese guy from 222.186.15.158) was attempting to connect to my NAS with the root account (Fortunately PermitRootLogin is disabled).

What I am a bit worried because if I see a public address here, it means my NAS is somehow reachable from the internet. However all ports are closed on my front router, NAT is disabled, DMZ is disabled.

When I try to nmap my router from the outside I get this :

$ nmap -Pn -p- x.x.x.x

Starting Nmap 7.60 ( https://nmap.org ) at 2020-05-17 01:07 CEST
Nmap scan report for x.x.x.x
Host is up (0.012s latency).
Not shown: 997 filtered ports
PORT     STATE  SERVICE
113/tcp  closed ident
2000/tcp open   cisco-sccp
5060/tcp open   sip

Nmap done: 1 IP address (1 host up) scanned in 8.23 seconds

So there is no SSH entry point.

How would it be technically possible to see a public IPv4 address attempting to connect to my LAN NAS?

From the Synology DSM I exported the last log entries from the Log Center.

System
Level,Log,Date & Time,User,Event,
Warning,System,2020/05/16 21:34:44,SYSTEM,Host [222.186.15.158] was blocked via [SSH].
Warning,System,2020/05/04 07:46:14,SYSTEM,Host [222.186.30.59] was blocked via [SSH].
Warning,System,2020/04/15 06:46:01,SYSTEM,Host [51.91.158.54] was blocked via [SSH].
Warning,System,2020/04/13 17:46:00,SYSTEM,Host [27.78.14.83] was blocked via [SSH].
Warning,System,2020/04/13 17:45:55,SYSTEM,Host [116.105.216.179] was blocked via [SSH].
Warning,System,2020/04/12 17:46:52,SYSTEM,Host [86.36.20.20] was blocked via [SSH].

This log is an SQLITE database directly connected to syslog-ng.

My router is a Salt Fiber Box from my internet provider. The interface is very primitive. Even the Expert mode gives no transparency about the Firewall features. I don't even know what Medium means in this case:

Some thoughts

From symcbean comment three scenarios are possible:

Something is already inside my network.

Then I would probably see attacks from local addresses it is stupid to give me the information of what is the IP of my attacker.

My router is compromised.

Unfortunately this options is conceivable

There is an issue with the information I gave.

As I said, no NAT/DMZ options are enabled on my router (screenshots attached)
The Synology has no DDNS configured, no tunnels, no VPN

From mti2935 comment

The router could be compromised, the attacker could have punched a hole for himself only accessible from his own IP (or range of IPs).

In this case I would expect this attacker to do a more massive attack, not few attempts every few weeks.

I might found the culprit, at least in my case, rsync.
I use rsync on my NAS and that port is open, has port redirection on my router and guess what it uses SSH, so that would explain why my NAS gives me those same SSH warnings eventhought SSH is turned off on my Synology.
Have had no more logs about bruteforce attempts on SSH sofar since I closed the port today.


Why Antiviruses does not check the library modules of exe to detect hook? I write a simple keylogger by C# in Windows (using Hook method SetWindowsHookEx). I checked my application with most antivirus and anti-spyware programs, but none detect it.

Why don't these antivirus or anti-spyware programs disassemble the executable to find usage of SetWindowsHookEx? I read that  over 80% of keyloggers use this hooking method .

This is to avoid what is called a false positive, i.e. when the user receives an alert about a danger while there was actually no danger at all.

Do you remember this rich era when, while you were browsing the Internet, you where facing a dozen of times per day an alert bow stating something like "Alert ! The web page you are viewing contains some secured elements and some unsecured elements ! Are you sure you want to proceed !". The result of this was just that people were trained to ignore their browser's alert message and blindly click on the OK button, which was fully counter-productive from the security point-of-view.

Now this is the same with your SetWindowsHookEx API call. An anti-virus has no way to determine the intent of a software, it can only rely on a subset of facts. So, maybe the use of this API call enters as a part of an heuristic taking into account several other parameters helping the anti-virus to determine when a software has got a suspicious behavior, but the sole presence of this API call is not sufficient since it is also used by many authorized applications (same thing if you write a simple Batch file deleting all your documents: your anti-virus will not prevent you from running it).

These are the very reason why, while anti-virus provide a good level of protection against well-known malware, it can never be a bullet-proof protection and the first and better line of defense remains the user who should be properly educated in recognizing and refrain from opening suspicious files.


Decompiling shellcode I'm trying to understand how shellcode works.
I wrote a simple program in C#, then I used Donut to create the shellcode from that exe in base64 format.
Then, I wrote again another program to convert the base64 shellcode in a sequence of bytes, in order to reproduce the original exe.
I noticed a difference: ILSpy is able to open the first one, but no the latter since it says "pe file does not contain any managed metadata", indicating that is not a C# program.
Moreover, there is a small difference in the size so definitively the checksum is different.
Could someone explain what happened? Is there a way to decompile this program?

C# (and other .Net languages) are compiled into Common Intermediated Language bytecode which is translated into native code "Just in Time" by the Common Language Runtime. This is similar to how java works. Donut converts the intermediate bytecode generated by your C# compiler into shellcode (i.e. native code which the cpu can process directly).*
ILSpy reverts Intermediate Language bytecode back into C#. It isn't designed to, and therefore cannot, convert shellcode back into C# code. Your second executable contained shellcode from Donut so ILSpy didn't find any managed metadata in it and couldn't decompile it. If you want further help for decompiling the shellcode, try asking at https://reverseengineering.stackexchange.com

*For further information on this, read Donut's own explanation


Does any tablet support remote attestation? Some PCs come with a TPM.  One of the nifty capabilities of TPMs is the ability to perform remote attestation.  Remote attestation allows your computer to tell a third computer what software your computer is currently running -- and this statement is signed by the TPM hardware, so malicious software cannot lie or subvert the mechanism.

Are there any tablets that support remote attestation?  (Or are there any smartphones that support it?  Is remote attestation even supported on any ARM or Atom chipset?)

When a TPM provides a remote attestation, several components are involved:

the TPM as a tamper-resistant device containing a root of trust;
the TPM as a device to measure the software running on the main processor and produce an attestation;
software to connect to the TPM and retrieve the attestation and transmit it (this software is merely relaying a signed attestation provided by the TPM, so it need not be trusted).

The third point is “easy” insofar as such software already exists, and could be ported to tablets if there was a use for it.
The first point is a blocker in the mobile device ecosystem, because phones and tablets tend towards having very few chips; an extra TPM chip is seen a as significant cost increase. While TCG has defined specifications for a MTM (a lightweight TPM for mobile devices), I don't think an MTM found in any smartphone for the general public. Microsoft is pushing for TPM in tablets, so MTM or TPM in mobile devices may become more widespread (e.g. the new Windows Phone 8 has a TPM).
Point 2 does not actually require a TPM as a physical device, but a system component providing a TPM-like interface and running outside the reach of the normal operating system. For example, the OS (e.g. Windows RT or Android) could run in a virtual machine, with the hypervisor providing a (virtual) TPM. There are two immediate hurdles with this approach:

The Cortex-A15 is the first ARM core providing virtualization extensions. Devices with A-15-based processors are barely coming out now.
While the hypervisor can store the root of trust outside the reach of the main operating system at runtime, it needs a place to store this root of trust — that can't be the main flash memory where the OS could overwrite it.

The first hurdle can be solved with TrustZone, which provides a kind of specialized hypervisor with just two OS partitions and is present on all ARM-based processors used in smartphones and tablets (and it's difficult as a user to know what if anything it's used for). The second hurdle requires more support in the processor, but there are processors deployed in existing devices (e.g. the Motorola Droid) that provide at least a small amount of non-volatile memory in the form of fuses (physical write-once) that are only readable by the “trusted world” side of TrustZone and not by the main operating system. A TPM interface can be built on top of that, and TCG is working on it. This may well be the “firmware-based TPM” in the ARM-based Surface (which does not have a discrete TPM chip).
So, to summarize: there are pretty much no tablets with actual TPMs. But there are tablets with something that can implement the same security requirements (with a slightly lower level of confidence). You can't yet buy any tablet and expect to have remote attestation working on it, nor can you implement it yourself because you won't get access to the root of trust, but with the current hype around BYOD, more and more products should be coming out.


Nogotofail usage android pentesting I was looking at the google tool: Nogotofail https://github.com/google/nogotofail

I used their examples to set it up and this works for the examples with proxychains.

But now I want to use it with my android device or android emulator (SDK or Genymotion). But this is where I just do not understand what I have to do.

I tried:
- Installing their "App" but this just crashes on my device or gives 2 options "SSL/TLS" and "HTTP" in an emulator and doesn't do anything
- Just proxying all traffic to my machine on 8443, this gives a lot of bad handshake errors in nogotofail
- Proxying through Burp to nogotofail, which gives the same bad handshake errors.

From google's documentation I understand that it should work on a router or VPN. But I don't understand how to get that to work via my normal computer, and why it would not work by just proxying (like Burp works).

I think I am missing some base level understanding of this problem, but the documentation doesn't help me with this.

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


Bitlocker/Filevault and VeraCrypt together? I'm researching ways to make the most secure encryption for additional fixed drives to protect against unknown vulnerabilities, side channel attacks, etc.

Basically, securing the data beyond just a single password on ALL drives. The OS utilizes a TPM and has secondary input measures such as a PIN.

It was my hypothesis that adding another layer of safeguards, such as an encrypted container within that, would provide substantially higher security. Not only would the drive encryption need to be broken, but also a separate container.

Yes, perhaps brute-force will take "trillions" of years to break, but one vulnerability can have it broken in a minute.

Conclusion:

Just use stronger encryption.

Discussion:

I don't think that a locked home with a safe in it is a good analogy for double encryption.

The security on most homes is similar to the security that rot13(*) provides: It keeps honest people honest, but a brick through a window or boot to a door provides access.

Double encrypting would be like putting a bank vault inside of another bank vault.

One thing that many people who talk about cryptography like to discuss, is how many operations it takes, on average, to decrypt something... Or more generally, how long it takes.

Safes (and locks, doors, and other physical security) are also rated for how long they can keep professional locksmiths out.  I.e., your door lock can be picked in under a minute.  A personal safe's lock mechanism can be drilled through, or the door itself pried off in 15 minutes.  There are ways to engineer a safe to increase the time it takes, such as a layer of glass that, if it shatters, locks the bolts in place, making it far more difficult to drill through the mechanism.  The walls can be reinforced and made thicker. Etc.

Rather than having a bank vault within a bank vault, people generally just increase the difficulty to access the outer vault, and make sure to secure the keys and combinations.  After all, if the attacker knows how to get into one vault, the already know how (and have had recent practice) to get into the second vault.

If your outer password is compromised, then it's best to assume that both of your passwords were compromised. Either the attacker has physical access to your device, or has access to your password manager.

Having two 128-bit keys is not the same as having a single 256-bit key.

If I angered a nation-state, who decided to throw a million GPU cores at my data, where each core could attempt a trillion operations each second, my first 128-bit key will fall in an average of 1 quadrillion (1 * 10^12) years.  My second key will fall about 1 quadrillion years later.  Effectively, I have a 129-bit key.

However, if I have a 256-bit key, it would be expected to last 300 quindecillion (300 * 10^48) years against the same nation-state.  That is several times the projected lifetime of the universe. In fact, if every star were converted into a Matrioshka Brain and put to the task of decrypting the data, then there might be a very slim chance to crack it.  Bruce Schneier, of course, would be able to crack it in an afternoon with nothing but a stick of charcoal and the back of an envelope.

(*) rot13, for those who might not know, is simply shifting over your plaintext by 13 characters, in the basic English alphabet. It makes text unreadable, but it is trivial to figure out the plaintext.


System for Mutual authenticaion and confidentiality I am looking for a protocol where there needs to be mutual authentication between client and server. For example server should connect to a particular client only. That is client should authenticate to client and client should communicate to server. Also after this all the communication should be encrypted.

Whether SSL/TLS can provide this? Or is there a method where by client could give password to authenticate himself to the server.

My primary requirement is that server should provide information to a particular client only.

There are two ways to achieve mutual authentication within SSL/TLS:

Use certificates. The server presents his public key within a certificate, as is customary; the client validates the server certificate with regards to some root CA that the client knows beforehand (this part is what commonly occurs with HTTPS Web sites). Then the server can ask for a client certificate, in which case the client must send a certificate and perform a signature, which the server will verify using the public key in the client certificate. The client is then authenticated under whichever "name" is written in this certificate. This is described in sections 7.4.6 and 7.4.8 of the TLS standard.
Use SRP. This is a Password Authenticated Key Exchange protocol in which the client and the server mutually authenticate through the knowledge of a shared secret. What is mightily cool about PAKE in general, and SRP in particular, is that the scheme is strong even when the shared secret is of low entropy (say, this is a "password"), because it resists attempts at offline dictionary attacks: in simple words, the protocol is such that if an attacker wants to "try" a potential password, he must interact with either the server or the client in some way, and must do so for every single try. The attacker never gains enough information to check passwords on his own machines only.

SRP avoids all the murky business of certificates. Unfortunately, SRP is not yet widely supported; GnuTLS is an opensource library which implements SSL/TLS servers and clients, and supports SRP.


Authentication and security of a REST API Scenario: I design a REST API where authenticated users can hit the API over TLS. I have to use TLS as the data transmitted over the wire is sensitive. I don't need authorization right now, but I don't want to exlude the possibility. I want to use some kind of API Key(/Secret) method. I would prefer to avoid using OAuth. I have two possible solutions. In both cases, the API key (and secret) would be generated by us.

I. Simple API Key

Include an API key in the HTTP header, I can authenticate the client based on that header. The API key is safe, because of TLS. Replay attacks are not possible, guaranteed also by TLS. Very simple to implement by our clients. As far as I understand TLS, the request cannot be tampered (MAC). All security measures are provided by TLS. The client only adds the API Key HTTP header.

II. HMAC signature with an API secret

The request should include a signature, hashed with the secret, timestamp and the hash of the request payload. Now it cannot be tampered or replayed and the secret is not even transmitted over the wire.
Safest, but hard to implement on the client side. (writing client libraries is not an option)

Does the first solution pose any threat and provide sufficient security to my clients (and our API), or I should use the more complicated second one? Also, what are the shortcomings of the first one?

If you're using TLS already, I would lean towards using a secret API key in the header.  With an API key you can store that encrypted which protects you in the case of a breach.  Make sure your application and server aren't logging the secret key in any form and I would push your client to use long, complex keys.  These will be handled by systems not people so there shouldn't be heartburn with having them present a long, complicated key with every request.

The hmac signatures are useful if you want to use an unencrypted channel and accept a little bit or risk.  In this case the HMAC provides no benefit and would require you to store the secret in plaintext.  In this case, I would consider a secret key to be more secure than a signature.

Performance-wise they are going to be similar.

One other note: Since you are TLS you should take care to make sure your example docs and howtos make it clear how to establish that connection correctly and alarm at certificate mismatches and your client SDK should do that by default.


Python implementation of AES and SHA256/512 that are FIPS-140-2 validated? For security purposes I  need to use AES encryption and SHA256/512 in my Django/Python project. I know there are various libraries out there that provide different encryption methods but I can't seem to find a library/package that is FIPS-140 validated. I was wondering if there is solution available for my need? if not which modules/packages are FIPS-140 compliance?

EDIT:

It seems that there is no FIPS-140-2 validated python package. However, AES, SHA-256 and SHA-512 are FIPS-140 compliance, so pycrypto or Cryptography can be used for AES encryption and SHA-256/512.

The closest I could get to a FIPS-140-2 conformance, is to build OpenSSL FIPS Object Module and use it as the backend for Cryptography. But then again since we are using a wrapper, it probably needs to go through FIPS-140-2 validation process again.

Thanks to @TerryChia for his helpful comments.

In the  FIPS publication you can see different annexes, in the Annex A: Approved Security Functions it says that AES, SHA-256 and SHA-512 are FIPS-140 compliance.

In the FIPS-140 validated list however I can't see any python module. Therefore seems that there isn't a python module FIPS-140 compliance, so you can use whatever python cryptographic module want if it has an implementation for the algorithms that you mentioned, maybe you can use pycrypto to encrypt using AES or to generate a message digest. Also as you comment cryptography could be a good possibility.

Hope this helps,


server with eth0 promisc-mode vulnerable to attacks outside firewall? If you use a passive network tap and a server with an Ethernet port in promiscuous mode to monitor all traffic between WAN port of your router and RJ45 port of your ISP cable modem.

Is the IDS instance running snort and snorby vulnerable to attacks from the Internet? Because it's placed outside the router, which usually acts as a firewall.

The connection to check the snorby website is done over a separate Ethernet port than the server which is connected to a LAN port of the router. You can only check the snorby website when you're within the LAN.

Yes.

There have been known vulnerabilities in the snort code that allow specially crafted packets to cause remote code execution and DoS. The problem for the attacker is knowing that snort is running, and which vulnerable version is running, but you still need to design your IDS to defend against such a possibility.


Our domain being spoofed by email addresses to try and spear phish us - how to prevent Ive been reviewing the emails blocked by our anti virus and have seen allot come from emile8@company.com (we dont have any users called this) with company.com being our domain, the emails all have the subject 'document request' and all according to our anti virus contain something (either trojan, virus, phishing etc..)

How can i prevent our domain being spoofed in this way ?

UPDATE:
We are using google apps for business email.
We also have an old email server from before we moved to google apps but the mx record is no longer pointed here. (its just left up as a backup copy of old emails, not sure if its even relevant but thought id mention it in case it was)

You can implement DMARC - https://dmarc.org/ - DMARC is a standard that allows you to specify mail servers that are valid for sending your email and contain some processes for filtering mail appropriately when it does not.


Is salting a hash more secure than encrypting it? Assuming most-secure algorithms used for either, what I'd like to understand and get the answer for, is whether a salted hash is more secure than an encrypted hash?

Although similar to this question (Salting in encryption, rather than hashing) I believe it is subtly different in that the question is about salting an encrypted hash.

From what I've read, in principle salting is more secure as the hash cannot be determined without knowing the salt value.

By comparison, a decryption algorithm "could" be cracked, therefore revealing the hash.

Encryption is the exact opposite of Hashing.

Encryption is reversible, by means of the key.
Hashing  is not reversible and there for only 1 way.

Now salting protects a hash from being pre-calculated and eliminates the risk  from pre-calculated rainbow tables (as long as there does not exists a rainbow table for the hash and salt combo).

Now Hashing also has a parameter of being 'costly', or in other words the act of hashing must take some time. (at least for passwords) as to eliminate leaking details about the process (e.a. time based attacks).

Encryption does not add any significant properties to the hash and it does not protect against rainbow attacks, like the salting does.

Often encryption is suggested by people that go not understand cryptographic hash functions and encryption. For 1 knowledge proofs (proving the password is correct without revealing the password) hashing is better than encryption.


sslstrip vs. privoxy redirect rule on clients I watched this video: http://www.securitytube.net/video/193 Now I'm thinking about an example.

Suppose I have a privoxy proxy on my PC:

user.action file (just part of it):
{ +redirect{s@http://@https://@} }
.foo.org

then I visit http://foo.org and get redirected to https://foo.org.

The big question: Am I protected against sslstrip?
What will happen? Will the page fail to load? Will using this kind of redirection keep my browsing safe?

Thank you!

This won't work very well.  If you try it, you'll probably find that you are unable to browse most sites, because most sites don't offer their site through SSL (https:).

The right way to defend yourself: install the HTTPS Everywhere extension for Firefox.  Any time you visit a web site that is known to support https, HTTPS Everywhere will automatically redirect your browser to use the https version.  It's great!  I use it and highly recommend it.

Important caveat: You will still be vulnerable to sslstrip / Firesheep style attacks when browsing sites that don't support https.  There's not much you can do about that, except ask those sites to support https, or avoid using unencrypted wireless networks.  (Or, buy a secure encrypted VPN service to route all your communications through: but that is inconvenient and expensive.)


Make secure connection with help of a server I`m curious. If a connection to some server is not secure, can that connection be redirected with one more server in between that will encrypt these files for you? What is that service called?

Basically, connection is made with server that will encrypt your requests and decrypt them for that insecure server, and the response will be encrypted on the way to your computer.

Congratulations, you have just invented the Virtual Private Network or VPN! They are usually used for all your communications and not just for a specific server. In addition, they also hides your real IP from the servers you connect to.

Do note though, that the connection will still be unencrypted between your VPN exit (the server in the middle) and the server you are connecting to.


Wireless hardware with limited range? I have never used wireless networking at home, but am considering it.  Does anyone make wireless hardware designed for single-room connectivity?

Several sources have recommended WPA2, but I'd still rather not be broadcasting outside the walls.

EDIT per AviD: My security concerns are that my broadcasting a greater distance than necessary, it opens my network to potential wardriving and other malevolent actions by people outside my location.

Regardless of what you do at the AP, I believe I can say with a fair amount of certainty that you will at some point find that your wireless data is being broadcast "outside the walls".

First, you must understand that your AP is not the only wireless transmitter on your home network.  All of your wireless clients that connect to the AP are also transmitting, and many probably cannot have their power manually adjusted.  Some adapters for laptops and desktops may have this option, but probably not all.  If you decide to put any game consoles, smartphones, or other such dedicated devices on your wireless network, they too probably lack this capability.  A number of these will likely reside adjacent or very near to one of your walls at one point or another, which practically guarantees signal leakage regardless of strength - almost all client devices are, after all, omni-directional transmitters.

Second, if you are attempting to defend against a real wardriver or dedicated threat, the signal output of your network really doesn't matter much to them.  What allows them to listen in on your traffic so well is a good quality receiver, which is entirely beyond your control.  High-gain, directional antennae are easily bought or home-brewed, and can often be made to pick up weak signals from a block or more away.  The only thing that will assuredly keep them from hearing your wireless network is to either not have one at all, or to put it inside a Faraday room.

In the end, using signal attenuation is not going to be so much an inconvenience to the outside threat as it will be to you.  A lower signal means that your devices may have trouble talking to or hearing each other from the far ends of your network environment, and they won't be able to compete as well with neighboring signals on or near the same channel.  For "single-room connectivity" the former may not be a huge problem, but in many places the latter can become a real issue.

The only way to be absolutely sure you're not broadcasting any substantial data outside your walls is to stick with the wire.  If you're really that worried about signal leakage, and you only need to cover one room, the convenience tradeoff is fairly minimal.

If you're really heart-set on going wireless, here's what you can do to provide some actual measures of security for your network.

Use WPA2 with AES encryption.  This is also commonly referred to as WPA2-CCMP or WPA2-RSNA.  For a home network, you'll likely be using the "Personal" or "PSK" option for this, which may be called "WPA2-Personal" or "WPA2-PSK".  If your network is a bit more advanced, and you know how to build a RADIUS server, you'll likely be looking for "WPA2-Enterprise".
Use a RADIUS server if you can, for authentication.  This is for very advanced users only, though.
Create strong passwords:

12 characters or more
Use all character types (uppercase, lowercase, numeric, non-alphanumeric)
Do not use any dictionary words
Do not make passwords related or similar to:

  User IDs
  Network's SSID
  Any device hostnames
  Each other (no two user passwords should be similar, and admin accounts should not have passwords similar to any user accounts)

If you must use a PSK, make it as strong as you can tolerate.  Absolute minimum would be to follow the password guidelines above.  My personal preference is a 63-character, randomly-generated code.
Configure MAC address filtering on your AP.  While this is a relatively minor roadblock, it's also a relatively painless one.  The only time this becomes a hassle is when you want to join a new device to the network for the first time, or if you do a factory reset of the router after having accumulated a large list of guest devices.
If it is an option, configure your router's management interface to use HTTPS only.
If it is an option, disallow access to the router's management interface over wireless connections.  This way, only someone who is physically wired into the router can make configuration changes.
Turn off wireless devices (including your AP) when they are not in use.  This will limit the availability of your SSID, authorized MAC address, and sample packets (for offline brute-force attacks) to potential attackers - the only inaudible signal is one that isn't there.
Use HTTPS wherever it is available.  This will add another layer of encryption onto your data transmissions, making your already nearly-impossible-to-crack signal that much more impossible-to-crack.
Use a VPN service while on wireless.  This will add yet another layer of encryption onto your data transmissions, making your already impossible-to-crack signal require God-like powers to break.

With the real issue being addressed, here's the answer to your actual question:

If you want to limit the general-access coverage of your wireless network, there are a few options.  Of course, these won't thwart a well-equipped wardriver or dedicated attacker, but they are available.

You can turn down the transmitting power on your AP, and on most wireless adapters in laptops or desktops.  Your AP will probably have an option for this somewhere in its management interface, but the availability and location of this will vary between devices.  I'm not sure what options are available for Macs or *nix systems, but for Windows you may find the option in the Advanced tab of your network adapter's Properties page in Device Manager, if it exists.  Again, this is likely not an option on many other types of client devices, and they'll just continue to send much of your really valuable data (usernames, passwords, uploaded documents, etc.) as far as they're designed and/or configured to scream.

If your AP has detachable antennae, try removing them and see how that works.  Surprisingly enough, a wireless AP may still emit and receive just enough signal for very near-proximity operation through just its bare connectors.  Still, this is likely not an option for your client devices, so they'll just continue to send much of the really valuable data (usernames, passwords, uploaded documents, etc.) as far as they're designed and/or configured to scream.

If your AP has detachable antennae, you may find some useful directional antennae that will help.  These can keep the signal pointed in only the direction you want it to go, if that is something that will work well in your environment.  However, these also will likely cause the range of your AP to over-shoot the distance you want to cover in that direction.  And still, this is likely not an option for your client devices, so they'll just continue to send much of the really valuable data (usernames, passwords, uploaded documents, etc.) in all directions.

If your AP has detachable antennae, and the lowest power setting isn't quiet enough for you, try adding a signal attenuator to it.  Still, this is likely not an option for your client devices, so they'll just continue to send much of the really valuable data (usernames, passwords, uploaded documents, etc.) as far as they're designed and/or configured to scream.

TL;DR:

Limiting the reach of your wireless network to one room is nearly impossible to actually accomplish, since many wireless devices (especially clients) lack the option to attenuate their signals and most transmit omni-directionally.  Further, it is of very little value since hackers commonly have specialized equipment that will easily pick up weak signals.  You'll likely do more harm to the usability of your wireless network, than you will do actual good.

Instead, you should focus on using real security measures such as WPA2-AES, strong passwords and PSKs, MAC address filtering, securing your APs management interface, turning off devices not in use, and using VPN.  If you're still worried about your signal leakage after that, you should avoid it by using a wired network.

If you're absolutely determined to reduce your wireless network's range, there are still a few options.  Most APs, and laptop/desktop wireless adapters give you the ability to turn down their transmit power.  Directional antennae, or use of no antennae at all can help limit your AP's coverage area.  Signal attenuation hardware for APs and some laptop/desktop network adapters are also available.  Still, any equipment on your network that cannot make use of these options will continue to send their transmissions far and wide.


Signing API requests with a private key: Does this key delivery scenario sound secure? I am a software developer but a newbie when it comes to online security.

Company A has some desktop software used by customers C and D (C unrelated to D).
Company B has a web service and has the same C & D customers.

C & D need A's software to connect to B's web service and import their specific data.

A contacts B and asks what is required to achieve this and is told to do the following:-
1) Create a private key
- openssl genrsa -aes256 -out chosencertificatename.key.pem 2048
- (add a password when prompted)

2) Create a CSR
- openssl req -key chosencertificatename.pem -new -sha256 -out
chosencertificatename.csr.pem
- (enter relevant information for certificate)

3) Send the CSR to B and get a certificate back
- You will be issued with a valid certificate for accessing the APIs.
- The certificate chain used to sign the request will also be issued.

4) Associate with you private key using a PKCS12 file
- openssl pkcs12 -export -out your_pkcs12_file.p12 -inkey your_private_key_store.pem
-in certificate_sent_from_nucleus.pem

5) Use in your application
- Embed the certificate in your application
- Each request must contain the Client (X509?) certificate
- Each request must also contain an X-USERNAME header to identify the customer
   (C and D will be given their own username tokens - plaintext ID?)

I am not sure this seems secure since it seems to me that the certificate can only identify that A's software generated the request; the X-Header seems to just identify whose data to return - if C finds out D's X-USERNAME then they can access D's data which seems even less secure than userID/password.

Also, is it safe to pass around a certificate that has a private key embedded in it?

Edit:
Rereading the instructions sent by B, it appears that A also needs to inform B which customers require access, the reason being that B can write to those customers confirming their permission to access data via the API.
Could it be that the certificate returned by B contains an embedded list of the validated X-USERNAMES?

if C finds out D's X-USERNAME then they can access D's data which seems even less secure than userID/password.

Can they? B might generate a separate certificate for each customer which can only be used to access their data. The X-Username header might simply be metadata. But you might want to try this out to be sure. Especially when they don't ask for which customer they are supposed to sign the certificate.


How to efficiently locate malware on an endpoint? I have a question from one of the interviews I had, I have no knowledge in system security and so I didn't know how to approach each. The question was:

  A customer suspects that one of his endpoints got infected by malware (OS is Windows 10 x64), and you were asked to analyze it.

  Build an analysis plan from the simplest techniques to
  more advanced methods. Try to focus on the most efficient and
  effective methods for detecting the malware.

  Avoid mentioning other trivial stuff like checking Firewall Settings
  or Security Updates, but rather concentrate on finding the malware.

I tried to look on the internet but couldn't find anything useful except for the same solutions of using Malwarebytes or similar programs. I guess it's not what's done in real situation when there is limited time to locate and isolate the malware.

Can someone tell me what are the key points to start with, or how to approach this?

from one of the interviews I had, I have no knowledge in system security

I know several people with CISSPs who would struggle to answer the question competently - what was the interview for? Really my question is what level of skill/effort is expected by the person asking the question?

  trivial stuff like checking Firewall Settings or Security Updates

That's a rather strange thing to say. if the interviewees first response was to start looking at the infection vector then the interviewer should be questioning their approach. OTOH, I would consider evaluating the infection vector a useful method of identifying possible candidates for the malware.

You should always start with the obvious/cheap checks:

  A customer suspects that one of his endpoints got infected by malware

My first step would be to establish why the customer suspects that. From then on subsequent steps branch out - there is not a single path which lead you to the answer in every case. You prioritize actions which will maximize the amount of information about the malware for the minimum amount of effort / cost.

Some of the things to look at:

is there a time when the system was in a known good state?

what files have changed since the known good state?

is there anti-malware installed on the system

is it working

if not, when did it stop

is it reporting anything

what processes are running?

how does this compare to a similar system which is not infected

etc.

At some point you may have to intervene with the operation of the system. While this is perhaps beyond the scope of the answer expected by the interviewer, it is essential to preserve the state of the machine before the intervention in order to identify the malware - even if we're not talking about a crime scene, mapping out the cause/effect network often requires backtracking.


Turn RPi3 Wi-Fi adapter into monitor mode using airmon-ng For some reason, I can't turn the built-in Wi-Fi adapter on the new Raspberry Pi 3 into monitor mode like I used to do on other platforms.

First I kill the processes that interfere with sudo airmon-ng check kill:

Found 4 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID     Name
364     avahi-daemon
385     avahi-daemon
411     wpa_supplicant
629     dhcpcd
Process with PID 411 (wpa_supplicant) is running on interface wlan0
Killing all those processes...

Then I try to enable monitor mode with sudo airmon-ng start wlan0:

Interface       Chipset         Driver

wlan0           Unknown         brcmfmac_sdio - [phy0]mon0: ERROR while getting interface flags: No such device

                                (monitor mode enabled on mon0)

The output says it's enabled, but I can't use mon0.
How can I fix this and turn the adapter into monitor mode?

You cannot. Not all chipsets/wifi drivers support monitor mode. Broadcom is known for lacking in open source drivers functionality support.

It is already public knowledge the RPi 3 current driver implementation does not support monitor mode.

PSA: The Raspberry Pi 3's embedded WiFi card does not support promiscuous mode.

If you are buying a replacement, do not go for a cheap realtek one, lots of bugs. Buy ralink or atheros, and check first if the chipset (and monitor mode) is well supported by the Linux kernel.

I am personally happy with this 8-10 Euro ralink, bought in Aliexpress: (link dead several times, replaced by the characteristics): 2T2R 300Mbps Dual Band 2.4GHz 5.8GHz-Ralink RT5572N WiFi USB-Adapter

see also https://unix.stackexchange.com/questions/252210/wi-fi-problems-using-asus-usb-n13-adapter-realtek


API key safety in front end app running in localhost I have been working on a front end (React) app that sends REST requests to an API end point.  I am aware that sensitive items such as API keys should not be stored in front end frameworks (like React, for example),
BUT...
Right now, I am just running the app from my development machine and the API keys are in one of my components so if I was to publish the app, the API keys would be easily stolen.
I was wondering what are some drawbacks and security considerations by running an app like I described only from localhost?

When running the app locally, you probably(there might be org policies beyond your control) have the power to create a safe environment to run the app.
So, you need to look at this from two main areas of concern:

Do you trust the browser and its extensions/apps that your app is running in? If no, then this is no different than the risks of running this app on another user's machine. If yes, then you should be fine.

Do you trust the machine that the app is running in? I hope the answer is yes because well, your source code is also on the same machine.


Why is it dangerous when an attacker can control the `n` parameter to `memcpy()`? I was reading a paper and saw this piece of code has an information leakage vulnerability. It was saying the following code will Leak memory layout information to the attackers

Could somebody please explain me how this leaks information?

struct userInfo{
    char username[16];
    void* (*printName)(char*);
} user;
...
user.printName = publicFunction.
...
n = attacker_controllable_value; //20
memcpy(buf, user.username, n);   //get function ptr
SendToServer(buf);

I can see memcpy will give exception but why should it return memory address to attacker(or whatever it is returning)?

Thanks in advance

Assuming buf's size is either controlled by n or larger than 16, the attacker could make n any number he wanted and use that to read an arbitrary amount of memory.  memcpy and C in general do not throw exceptions or prevent this from happening.  So long as you don't violate any sort of page protections or hit an invalid address, memcpy would continue  merrily along until it copies the amount of memory requested.

I assume that user and this vulnerable block of code is in a function somewhere.  This likely means it resides on the stack.  All local function variables, the return address, and other information are contained on the stack.  The below diagram shows it's structure in systems using intel assembly (which most platforms use and I assume your computer does).

You would be able to get the return address using this method if you were to make n large enough to cause memcpy to move forward in the stack frame.  user would be in the section in this diagram labeled "Locally declared variables".  EBP is a 4 byte value, so if we were to read past that and them copy the next 4 bytes with memcpy, we'd end up copying the return address.

Note the the above depends on what architecture the program is running on.  This paper is about iOS, and since I don't know anything about ARM, the specifics of this information could be somewhat inaccurate.


Can ransomware virus be removed from an affected PC? I have had a ransomware attack that has only encrypted some files. Is there any way to find the virus and prevent it from encrypting more files?

The best way to deal with a ransomware is to take out the plug immediately and remove the hard disk. You should always have a backup of the hard disk. Removing ransomware from a system is not that easy and a tedious task. The best way is to abandon the system and take a back up of all your data.


Does a hacker know which IP they hacked? Suppose someone hacks my computer (by any means, say a virus or trojan like RAT), will they be able to know my IP address in real time? This is about dynamic IP addresses.

Suppose someone hacks my computer (by any means, say a virus or trojan
like RAT), will they be able to know my IP address in real time? This
is about dynamic IP addresses.

Yes,By "hacking" your computer,i am guessing you mean popping a shell on the system,they would know the public/private IP address of the system when they receive the connect back or when they connect to your system by opening your system ports.


What possibly can be done with a public key? I installed Android Terminal Emulator on one of My Android Device (4.4 with kernel v3.10.28) to execute some linux commands and after a while found file called unlock_key. I executed cat command to see it's contents.

I have a few questions in mind :

What is the purpose of this unlock_key ? Is it for unlocking the device ?
What encryption scheme or algorithm is being used to generate this public key ?
How can I decrypt this to get plain text ? Is that possible ?
Is there a way to get private key corresponding to this public key ?

What is the purpose of this unlock_key ? Is it for unlocking the device ?

No idea.

  What encryption scheme or algorithm is being used to generate this public key ?

The public key is not encrypted. But it is probably a 2048 bit RSA public key.

  How can I decrypt this to get plain text ? Is that possible ?

Since it is not encrypted you cannot decrypt it.

  Is there a way to get private key corresponding to this public key ?

Practically impossible.


Why do "remote desktop" software (allegedly) commonly have a "blackout" feature? I've been watching videos of scammers being tricked. Frequently, the scammer makes their scam victim install some weird "remote desktop" program claimed to be for tech support purposes. These programs apparently allow the person connecting to the host (victim) computer to "black the screen" so that it becomes impossible for them to see what's being done.
Why would any legitimate "remote desktop" software have such a feature? What non-scam purpose could there be for that?

So that passers-by cannot see what you are doing on your computer.
If you are connecting remotely to a computer in an office, then everyone could see everything you type and you would not know.
It is a basic, expected, and legitimate feature. (By the way, that's the top 8 remote desktop programs each with a "blank screen" feature for the express purpose of privacy. I could keep looking up more apps, but that would seem to be redundant.)


Why RedHat Linux has obtained separate FIPS 140-2 certificates for OpenSSL , NSS, Kernel Crypto API etc? I am wondering why RedHat Enterprise has obtained separate FIPS 140-2 certificates for OpenSSL , NSS, Kernel Crypto API etc. Is it not enough to have FIPS 140-2 certification for only one cryptographic library i.e. OpenSSL, as all the libraries are providing almost similar functionalities ?

Thanks for any response/reply,

Regards,

as all the libraries are providing almost similar functionalities ?

It does not matter if they have similar functionalities because they have
different implementations. The certification not only includes if a specific algorithm is implemented at all but also if it is implemented correctly.


open redirect via POST? HTTP Request(POST):

per_page=security.stackexchange.com&order=questions&redirect=HTTP://security.stackexchange.com/

So when I record my request I get these 3 parameters and when I edited it a little bit, then click forward(Burp Suite), then I get redirected to the given site (in this case I get redirected to security.stackexchange.com).

So my questions is: Is my site vulnerable to Open Redirect? and is it a serious security vulnerability?

If all you need to do is paste that link into the browser and you're redirected to http://security.stackexchange.com then yes it is a vulnerability.

The seriousness of the vulnerability depends on the expectations of the site and how much a user trusts it. If I can send some person a link to your site that contains a redirect to my malicious site, and they think "oh, that's important I need to click it" then its fairly serious. That redirected link can take them pretty much anywhere, which could lead to phishing, malware, etc., all the while the user thinks they're being taken to your site.


would threat modeling help in scanning code? threat modeling would definitely help in determining the test cases and where to fuzz but my question is specific to code scanning. Would threat modeling help in focusing/prioritizing or any way static code analysis?

In short, yes it would. But you could also use a simple triage approach if threat modelling is too much of an overhead.

In detail -

Code analysis can be a time consuming activity. Even tool lead approaches will generate large amounts of output that will require human review and prioritisation. As such a threat modelling approach can help to identify and triage that effort. This becomes especially important in large code base reviews.

From a threat modelling point of view I would break the code down in to the following areas (in order of importance):

Code that has unauthenticated access.
Code that is authenticated but widely accessible.
Code that is authenticated and restricted to a defined and trusted
minority (such as a limited subset of code used by admin function).

This will give you a prioritised approach to the code review and a framework for assigning the appropriate level of risk to each finding, for example - a flaw within code handling user input from an unauthenticated space could be seen to present a higher priority to fix over that of the same type of issue within a limited and trusted area of the application.

As requested this is now combined with the reply from @this.josh (this is an edited version, read @this.josh reply for the full text, it's worth the read)

If you are looking to do a more thorough job then you need to consider exposure:

Is some code run more often?
Is some code easier to pass data into?
Is some code more easier to debug to see the effects of?
What resources are accessed by the code?
What is the code protecting? (the assets)
What code relies on hardware for protection?
What code relies on other code to protect it? (what is your protection model?)
What code provides fault tolerance or error recovery?

Considering threats, exposures, assets, and the protection model will help you make good choices about what to test and how to test it.


safe to use jBCrypt and recommend it to my organization? I'd like to recommend to my fellow developers that we all use bcrypt to hash stored  passwords.  We all use java and I hesitate to recommend jBCrypt only because its latest version number (0.3) indicates that it is a beta release.  I see that recent versions of Spring Security have included an implementation that is mostly the exact code from jBCrypt.  By "mostly" I mean that Spring Security has changed it to meet their coding conventions and little else that I can detect.  To me, Spring Security is a pretty good stamp of approval.  My question is:  would you all feel comfortable recommending Spring's implementation?  If I test it and compare the results to actual bcrypt results, would this be good enough?  How would I know if my tests were thorough?

You could audit the jBCrypt code yourself. It is small: one 750-line source code file, half of which being an array of constants. Moreover, since this is Java, you do not have to fear the dreaded "undefined behaviour" of C: if it works well on your machine, it will work well everywhere (for that kind of code, which does not involve threads, system access of floating point computations, the "write once, run everywhere" mantra of Java tends to be true).

You can also have a look at the accompanying TestBCrypt.java file: this looks like a reasonably thorough application of known test vectors (including some non-ASCII passwords). The code looks fine to me.

For most opensource projects, version numbers are meaningless, since they translate more the author's feeling of inner fulfillment than any actual technical quality of the software.

Note: of course, since the point of slow hashing is a budget race between the defender and the attacker, by using Java you are giving a 3x advantage to the attacker: he will use optimized C or assembly (or some FPGA). Yet, properly applied bcrypt, even with Java, should be enough to ensure that password storage is no longer the worst of your problems.


Separate public and private key for EC Our architects are trying to use non-standard using asymmetric cryptography. They want both the public and private keys kept private. It means we have 2 systems: 1st system working only on encrypting data, and 2nd - working only on decrypting data. Both systems have a different part of the key. In base we have EC alg and systems on JAVA.

Asymmetric algorithm, means than you encrypt with a public key, and decrypt with the private. But in keystore we can not store the private key without the public. (Public without private is fine, it's like truststore).
I tried convert the keystore to p12 and do openssl pkcs12 -in yourP12File.p12 -nocerts -out privateKey.pem

After:

PEMParser pemParser = new PEMParser(new FileReader(privateKeyFile));
    Object object = pemParser.readObject();
    InputDecryptorProvider pkcs8Prov = new JceOpenSSLPKCS8DecryptorProviderBuilder().build("password".toCharArray());
    JcaPEMKeyConverter converter = new JcaPEMKeyConverter().setProvider("BC");
    PrivateKey privateKey = null;
    if (object instanceof PKCS8EncryptedPrivateKeyInfo) {
        final PrivateKeyInfo privateKeyInfo = ((PKCS8EncryptedPrivateKeyInfo) object).decryptPrivateKeyInfo(pkcs8Prov);
        privateKey = converter.getPrivateKey(privateKeyInfo);
    }

In this private key I see public key (reflection), and I can extract it.
The command openssl ec -in privkey.pem -pubout > key.pub works fine too. One way, that I see, if we read private key from jks, it doesn't contain the pubKey. And we can serialize it to java Serializable and save it. Is this a good method to save the public and private key separately?

It is very risky to make non-standard use of encryption functions. All sorts of subtle problems tend to creep in; problems with existing tools being just some of them.

Presumably, this design was chosen to ensure both confidentiality and authenticity. A better solution would be to have two key pairs: one belonging to the originator of the data, the other to the receiver. Each would share their public key and keep their private key secret. When creating data the originator would encrypt with the receiver's public key and then sign the encrypted data with their own private key. The receiver would first verify the signature and then decrypt.

This solution will provide both confidentiality and authenticity while working just fine with existing tools and expectations.


How many people would need to answer a survey of 1000 questions before the aggregate data from the survey is sufficiently anonymous? Websites release statistics on their user base all the time and it’s not considered a breach of privacy because their user bases are so large that it’s impossible to pick apart who thinks or watches what. Additionally when nations or states or counties release election results it is impossible to figure out who voted for what even if the county has a miniscule population.
To be clear if the population is 1 then the results are never anonymous, and the more people there are the harder it is to see who answered what. Assuming that we know everyone in the voting pool.
But let’s say a survey with 1000 yes or no questions is released to all the residents of a county and when the survey was over results were shown which were based on a system of 1 for yes answers and 0 for no answers giving you totals for each question.
Do the more detailed results make it easier to piece together who said yes or no to what?
And if so how many people would need to answer the survey before the results were completely anonymous? Or sufficiently anonymous?

You're asking what is the number n of survey respondents such that n is higher than the threshold for anonymity. I feel like this is putting the cart before the horse. To answer questions about how many responses you would need for it to be anonymous requires knowledge of the population, which is the entire point of a survey. That leads us to...
A concept called k-anonymity. It's not strictly what you're asking for. But k-anonymity looks at the existing data and determines strategies for altering it to provide anonymity. In theory, this would work on whatever size data set you end with. The caveat being that the suppression and generalization operations required could render the data less useful.


How to safeguard physical keys stored in a fire dept. lockbox? The workplace has a physical access key stored in a fire department lockbox (sometimes called a Knox Box), how it's possible to mitigate the risk that the Knox Box gets picked, or that an unauthorized key may exist?

What could the local fire department ask for to remove that key?

To be clear: a Knox Box is a lock box that holds keys for emergency personnel. If the fire department needs to get inside your building while it is locked, the fire crew will have a key to unlock your Knox Box and retrieve your building's key.

There are a couple of ways to mitigate this risk. The easiest IMO is security cameras that watch your doors. If someone unlocks the Knox Box and uses your key, the camera will pick them up and you can respond appropriately.

What I often see either to automate this or in conjunction with this is, the Knox Box is hooked up to an alarm system. When it's unlocked, the alarm goes off alerting your security company that someone has obtained access to the key. If it's a true emergency and responders are on scene, this will not have any impact. If it's not an emergency and it's a burglar, the police will now be notified to respond.

Most Knox Boxes I've seen have a hookup to wire them into a security system. Here is a link to a fire department recommending this approach.


How does the padding scheme impact the security of encryption After digging a little deeper into cryptography I am wondering what impact the different padding schemes do have an the security of an encryption algorithm. Lets take AES-128 in CBC mode as an example, because I am currently working with this one.

Wikipedia lists several padding schemes but does not mention anything about the security impact of choosing one of them. The library I am currently working with supplies PKCS5 padding, which is not even mentioned in the Wikipedia article. There are obviously several more padding schemes out there.

I am not an expert in cryptography, so maybe I am totally wrong, but I cannot see how the different padding schemes should have a significant impact. Am I basically free to choose one and be happy or are there some things I have to consider?

Short answer: Don't sweat it.  In most cases, the choice of padding method doesn't matter.

Longer answer: why it doesn't matter.  As long as you use proper crypto design practices -- in particular, as long as ciphertexts are properly authenticated -- I'm not aware of any way that the choice of padding affects security (with one exception, see below).

It's true that if you fail to authenticate the ciphertexts, then there can be attacks, as @Thomas explains.  Then again, if ciphertexts are not properly authenticated, you've probably got a host of other problems, so you shouldn't blame this on the padding scheme.  Cryptographers know that if you encrypt something, you really should be authenticating the ciphertext; failure to do so is a classic rookie mistake that can open up serious security flaws.

In short, if you're following good crypto practices, the choice of padding shouldn't matter much for security (and if you're not following good crypto practices, you may have bigger problems).

The exception: a case where it does matter.  OK, now we're down to the fine print.  This is where I admit that the above is a bit of an oversimplification.  There is one situation where the choice of padding may be very important to security: resistance to traffic analysis.

Encryption does not conceal the length of the messages being encrypted: the encrypted message typically reveals the length (or approximate length) of the message that was encrypted.  In some contexts, this can be highly problematic.  For instance, there are contexts where revealing length information gives away the entire store: it reveals the stuff you were trying to keep confidential.  (See, e.g., Chen et al's astonishing side channel attacks on SSL-encrypted web applications.  Among other things, they showed that an eavesdropper who observes the lengths of network packets while the user is typing in a web search query can infer what the search query was.  I think Google fixed the problem, but it was a stunning, eye-opening example of a general risk that was previously known.)

If you are in a context where message lengths reveal sensitive information, then you have a problem.  The standard defense is to pad the messages before encryption, so that the ciphertext length does not reveal anything about the message lengths.  One way to do this is to pad all messages out to a fixed length, before encrypting.  Another (less secure) way to do it is to add padding of a random length, with enough random padding that the random noise obscures the signal and prevents an attacker from learning enough information about lengths to do any harm.  So, in a context where we need to prevent traffic analysis, the design of the padding scheme becomes critical, and standard padding schemes are probably not going to be enough: you may have to do something special.


Hardware encrypted external HDDs I'm planning to buy an external HDD with hardware encryption, namingly the WD My Passport Ultra 2TB. On the WD website the information about the encryption is sadly scarce so I'm asking here.

How secure are these encryption implementations in general (I think the above mentioned model uitilizes AES-256)
How inter-OS friendly is the en/decryption and the subsequent accessing of the data (Windows, Linux/Unix and possibly MacOS) ?
Is the unallocated/empty space on the disk encrypted as well, or just the sectors where data is allocated?

On software encryption vs hardware encryption, read this comparison on Kingston's website, and your choice may be easy, but this is marketing language.

I'm quite sure that Open Source software encryption like GPG is more secure. See this question: Is hardware based disk encryption more secure that software based?.

The basic question is: from who do you want to be protected? The NSA? Hardware will not work. They can probably read the encryption key from the chip. Software will not be safe without a good and long password. However, when the disk is stolen, most people will just erase it, and in that case it will protect you good enough.

If one of your friends wants to copy your data, he has probably better ways to get there, like installing a rootkit or something.

The WD disk seems to be OS friendly. See this review.


Difference between non-repudiation and plausible deniability I've read in some books the 'goals of information security', which includes non-repudiation.

My understanding of non-repudiation is that if Alice sends a message to Bob, Bob is not only convinced that the message came from Alice but he can also prove to Carol that the message indeed came from Alice (assuming Carol doesn't trust Bob)

Recently, while watching a talk of Moxie Marlinspike, I learned that non-repudiation is not necessarily a good thing (you might want to deny authorship of a message to the world), and hence he spent time to develop this new protocol (Axolotl) which has a thing called 'plausible deniability' which I assume is that if Alice sends a message to Bob, Bob can be certain that it came from Alice, but Bob cannot prove to Carol that it did actually come from Alice.

Now, to a beginner, those two ideas are kind of contradictory and hence the confusion and this question (and the following sub-questions).

Have the goals of information security changed?
Are there specific use cases where either of the two (non-repudiation and plausible deniability) is useful to have? (An example would help a lot)

As in any other aspect of life, one might have different information security goals in different situations. There are situations in which you want non-repudiation and there are situations in which you would want plausible deniability. Likewise, there are situations in which you would want non-repudiation on some aspects but plausible deniability on others.

For example, let's say you've made a deal with someone and want to sign a contract with them. Such a contract would not be of much value if one of the sides of the contract could later deny signing it. Each of the sides to a contract wants non-repudiation on the other side's signature.

On the other hand, consider the case where you are a whistle-blower informing the authorities of some grave crime being committed by your employer and you're worried your employer may discover your leak. In this scenario you would want plausible deniability.


Store Credit Card Information in Password Manager? For convenience purposes I manage my passwords with the password manager Bitwarden on my personal computer and smartphone with autofill function (but with asking for the master password or fingerprint first every time).

I was just thinking about also adding my credit card information (which is used to log into the online banking stuff) to my vault, but since that seems like such important data, I'm not sure if it would be safe or if this even is a good idea. Any opinions?

I also saw this question on here, but it rather deals with whether that is reasonable from a law standpoint.

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

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

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

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

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

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


How to recognize the machine from which a request is coming? At my work there are certain internal sites which I can access from my home but only through my work laptop. I wonder how this works. When my work laptop is connected to the corpnet, it has one IP address. When the machine is connected to my home network it has another IP address. Still the server is somehow able to distinguish whether I am trying to access the site from my work laptop or personal laptop. How is this possible?

There's a few different things that could lead to this.

There could be a VPN that's automatically established for you for those hosts, even if you use another VPN at work.  Many enterprise VPN clients can have complex configurations, and are able to detect whether they are on your corporate network or not to perform the VPN connection.

Another possibility is that your computer is configured to use specified DNS servers instead of those provided by your home router or ISP.  In that case, your work DNS servers might be able to return results for the affected sites while your home computer is not able to resolve those hostnames.

In some (higher security) environments, computers are issued SSL client certificates (often backed by a TPM-stored key).  In that case, the server can look for the certificate to verify the incoming connection as being from an authorized client (your work laptop) and only allow access to those hosts.


Filtering out JavaScript from HTML to prevent XSS? I'm having an exercise to patch an older version of my work from university's e-class. It's written in PHP and requires version 5.3.27. One of the things I want to patch is to prevent XSS. The site uses an old editor (xinha) which supports HTML input without any validation, so XSS is extremely easy to do.

I am not allowed to change the editor so I intend to change the server side validation before using/storing the user input to block event functions (like onerror, onmouseover etc.) and JavaScript. After quite some researches I didn't find any (foolproof) way to filter out JavaScript from HTML. Blocking HTML special characters wont work for me because it will break the HTML tags. Any ideas?

Filtering out JavaScript from HTML is a very complicated thing to do, especially if you cant restrict the allowed tags and attributes to a small set (or, preferably, none). To get this right is suprisingly complicated and there are many pitfalls. One mistake is all it takes to be vulnerable.

So don't go about this on your own. Use an existing, tried and tested library. For PHP HTML Purifier is a popular one, but I am sure there are more options out there.

In addition, you should use a restrictive content security policy if possible. But don't rely on that as your only line of defence.


Does LastPass' multi-device functionality significantly compromise its security? I think LastPass is a great consumer product because it allows users to conveniently utilize unique strong passwords for each site they use it with. It does encryption locally, but the fact that I can set it up on one computer/device and then use it on another computer/device seems to indicate that there must be some security trade-off for its consumer-friendliness. For example, the salt element of the password derivation algorithm presumably must reside on their server rather than on my own computer/device. Is my understanding correct? (Pardon me if anything I've said is uninformed, I'm not a cryptographer).

If you're looking to compare a cloud service like LastPass to a local application such as KeePass, then yes, there is a security tradeoff.

With an application such as KeePass, where you have full control over the storage of your password database (presuming you're not putting it up on DropBox or something), the only attack surface you have to worry about is your own system and the devices on which your password database is stored.  Generally speaking, these are not likely to be subject to targeted attacks (or, as the media likes to call them, APTs).  As long as you follow regular security best practices on your system (apply software updates, use antivirus, keep a properly configured firewall and/or router between you and the Internet, etc.), your password database is probably safe from Internet-based threats.

Note that I am not comparing local threats (involving physical access) here, because this is something that affects both options pretty much equally - you must have a local copy of your password database somewhere in order to use it, so you will be equally vulnerable to physical threats regardless of whether you use a cloud-based or local-only solution.  That is not to say these systems are especially weak against local threats - protecting the database with a strong password and encryption algorithm largely mitigates this - but that one is not likely to be much better than the other in such scenarios.

In the case of LastPass and other cloud-based password managers, the attack surfaces and associated threats are much larger.  Their systems are always on, and are very high-profile and high-value targets.  If someone ever totally pwns LastPass, there's no telling what sort of systems they might find access to.  While I'm sure they take their site security very seriously, they are likely subject to just as many attacks as any of the other user-trusted services that have been hacked recently.  As the saying goes, it's not a question of if they will be hacked - just a matter of when.  On top of that, you still have to worry about the security of your own system(s) which synchronize with LastPass.

Are LastPass or other clould-based solutions a tradeoff of security for usability, compared to locally-managed options such as KeePass?  Absolutely.  Is it worth it?  That's for you to decide.

EDIT:  To clarify on the issue of what is stored on LastPass' server...

They don't just store data for hashing/salting your master password on their server.  Though that is an important, key piece of information to be worried about, the real concern should be that they need to store everything that you want synchronized between your devices on their systems.  That is, if someone ever does hack LastPass and cracks your master password from their database, they will be able to access all passwords and other details that you have synchronizing between your devices without ever having to actually touch your own devices.

With a locally stored database, like KeePass uses, you don't have to worry so much about such attacks.  That is not to say it would be impossible for someone to break into your KeePass database over the Internet.  It's just much less likely they will be trying to, and it is a much easier threat for you to mitigate yourself.  (Besides, if an attacker across the Internet can crack open your KeePass database - and you use the same system to log into the things for which the database holds passwords - you're probably pwned enough already that it wouldn't matter anyway.)


Is there a way to sniff packets of a remote IP address? I would like to know if sniffing packets of a remote  IP address is possible at all, if yes I would like to know:

what is the success rate, I mean how much percent of the packets you would capture?
What are the benefits of securing the local LAN if someone can capture all the packets from that LAN simply by sniffing the WAN connection?
What are the ways to prevent that, and if there is a way to prevent the attacker from knowing my DNS queries and by that knowing to what web sites I am surfing.

If you have control over the network, you can sniff traffic remotely by using a vlan as the destination for a span port and then trunking that to where you need it. You can do this over routed networks as well using GRE tunnels but you must control the network.
1) If you have control of the network you should be able to capture 100%
2) You can encrypt WAN connections using IPSec either from host to host or at the routers that connect to the service provider to prevent the service provider from viewing the data.
3) This sounds more like you are worried about spyware on your workstation. If you have malware on the box, it really doesn't matter what else you do. You need to clean the box.


Concepts of PKI Encryption and Digital Signature Authentication I am trying to understand how SSL uses PKI and Digital Signature authentication to ensure secure and verified communications.
I've read various sources online and from what I can tell the basic process is:

A Server is given a Certificate from a Certificate Authority (CA).
   This Certificate includes (at minimum) the Public Key of the Server and a Digital Signature.
   The Digital Signature is some 'token' data encrypted with the CA's Private Key.
The Server sends data to a Client. It also sends the Digital Signature with it.
The Client checks that this CA is trusted by looking for it in a hard-coded list of CAs on the local system.
The Client can verify this Digital Signature by decrypting it using the CA's Public Key and checking for the original 'token' data.
   The Client now knows that the Server is trustworthy, according to the CA.
The Client sends data to the Server, encrypted by the Server's Public Key and an algorithm e.g. RSA.
The Server decrypts the data using it's Private Key.

I would like to know if this understanding is correct from a high-level, and if not, what have I got wrong/missed? Or any sources I should read elsewhere that will help.

We have a canonical question which gives a very detailed explanation of TLS: How does SSL/TLS work?

I'll answer your specific question:

  With RSA at least, the sever encrypts the message via the private key and this can only be decrypted with the public key... but as the public key is available to everyone how do we know that someone else hasn’t intercepted it?

Say I have a message:

I, Mike Ounsworth will give $10 from account XXXX-YYYY-ZZZZ to petehallw account XXXX-YYYY-ZZZZ.

I want to sign this message so that:

Everyone knows that it came from me
Nobody can tamper with it and change it from $10 to $1000, or change the account number.

If you look inside an RSA-sign operation, it would look sorta like **WARNING: OVER-SIMPLIFICATION ALERT**. First I hash the massage:

SHA2("I, Mike Ounsworth will give $10 from account XXXX-YYYY-ZZZZ to petehallw account XXXX-YYYY-ZZZZ.")
= 521C5EC6F1FEE551A2A5A8967EE183369424DBD26C4F25337EF72C42D01DB7E1

Next we compute a signature on the hash value (you have the mental model of encrypting that SHA256 hash with the private key, which is ok, but we aware that it's an over-simplification).

RSA-sign("521C5EC6F1FEE551A2A5A8967EE183369424DBD26C4F25337EF72C42D01DB7E1", privateKey)
= <binary_signature_blob>

Then anyone with the public key can verify by:

Computer their own SHA256 hash of the massage they received.
Use the public key to "extract" the SHA256 from the binary signature blob.
Make sure the two SHA256 hashes match.

As stated above, this is already an over-simplification, even for RSA which is the simplest cipher to understand. You said that the different articles you read seem to disagree on how RSA signatures work, that's probably because crypto is complicated and each article is probably simplifying down to layman's terms in a different way.


Can a PDF file contain a virus? Could a PDF file contain any type of malware?

There are many features in the PDF that can be used in malicious ways without exploiting a vulnerability.  One example is given by Didier Stevens here.  Basically he embeds an executable and has it launch when opening the file.  I am not sure how today's versions of readers handle this but its a good method of using PDF features in malicious ways.