Category: Technology

Internet Privacy (Or Lack Thereof)

Well, the House passed Senate Joint Resolution 34 — which essentially tells the FCC that it cannot have the policy it enacted last year that prohibits ISPs from selling an account’s browsing history. What exactly does that mean? Well, they won’t literally sell your browsing history — anyone bored enough to peruse mine … I’d happily sell my browser history for the right price. But that’s not what is going to happen. For one thing, they’re asking for lawsuits — you visit a specific drug’s web site, or a few cancer treatment centres and your usage is indicative of specific medical conditions. An insurance company or employer buys your history and uses it to fire you or increase rates, and your ISP has created actual damages.

What will likely happen is the ISPs become more effective sellers of online advertising. They offer a slightly different service than current advertising brokers. The current brokers use cookies embedded on customer’s sites to track your browsing activity. If you clear your cookies, some of their tracking history is lost as well. If you use multiple computers (or even multiple browsers on one computer), they do not have a complete picture of your browsing because cookies are not shared between browsers or computers. If you browse in private mode (or block cookies, or use a third-party product to reduce personalized advertising), these advertisers may not be able to glean much about you at all. The ISP does not have any of these problems — no matter what computer or browser I use at home, the ISP will see the traffic. Since their traffic history is maintained on their side … nothing I can do to clear the history. Browse in private mode or block cookies and you’re still making a request that transits the ISP’s network.

The ISPs have disadvantages, though, as well. When you are using encrypted protocols (HTTPS, SSH, etc) … the ISP can see the destination IP and a bunch of encrypted gibberish. Now *something* about you can be determined by the destination IP (hit 151.101.129.164 a lot and I know you read the NYTimes online). Analysis of the encrypted content can be used to guess the content — that’s a bit of research that I don’t believe is currently being used for advertising, but there are researchers who catalog patterns of bitrate negotiation on YouTube videos and use it as a fingerprint to guess what video is being watched using only the encrypted traffic. Apart from some guessing, though, the ISP does not know exactly what is being done over encrypted communication channels (even the URL being requested – so while they may know I read the NYTimes, they don’t know if I read the political headlines, recipes, or concert listings out on LI). Cookie-based advertisers can, however, track traffic to encrypted (HTTPS) web sites. This is because site operators embed the cookie in their site … so where an ISP cannot read the data you transmit with an HTTPS site, the server in question *can* (otherwise it wouldn’t know what site you requested).

So while an ISP won’t sell someone a database of the URLs you’ve accessed last week, they will use that information to form advertising buckets and sell a specific number of ads being served to “people who browse yarn stores” or “people who read Hollywood gossip” or “right-leaning political activists”. Because they have limitations as well, ISP ad brokerages are unlikely to replace the cookie based individualized advertising. I suspect current advertising customers will spread their advertising dollars out between the two — get someone who can target you based on browsing over HTTPS and someone who can target you even if you block cookies.

What about using VPN or TOR to anonymize your traffic? Well, that helps — in either case, your ISP no longer can determine the specific web sites you view. *But* they can still categorize you as a technically saavy and security conscious individual and throw you into the “tech stuff” and “computer security stuff” advertising buckets.

You can opt out of the cookie-based individualized advertising — Network Advertising Initiative or Digital Advertising Alliance — an industry move that I assume was meant to quell customer anger and avoid government regulations (i.e. enough people get angry enough and are not provided some type of redress, they’ll lobby their state/federal government to DO SOMETHING about it). The ISPs will likely create a similar set of policies and a process to opt-out. Which means the being passed to the president for signature essentially changed the ISP’s ability to use my individual browsing history from an opt-in (maybe as a condition of a lower price rate) to an opt-out (where I have to know to do it, go through the trouble of finding how to do it, and possibly even keep renewing my opt-out). Not as bad as a lot of reporting sounds, but also not a terribly constituant-friendly move.

A couple of links to the current targeted marketing opt-outs for companies which whom I do business so bothered to waste a few hours trying to determine how to opt-out:

https://pc2.mypreferences.com/Charter/TargetedDigitalMarketingAds

https://www.t-mobile.com/company/privacy-resources/your-privacy-choices/ad-options.html

 

Selling Internet Usage

Thanks, Senate Republicans, for eliminating the regulation prohibiting ISPs from commoditizing individual’s internet usage. The headlines I’ve seen for the past day (“your internet browsing history can now be sold”) fail to take into account how well targeted advertising works … and the real world answer seems to be ‘it depends on how targeted’. Target, many years ago, ran some experimental ad campaigns based on data mining predictions. A combination of purchases indicate that a woman is pregnant — and reality about dealing with a baby mean that whatever you start doing is apt to be the thing you do for a few years. Buy diapers at Target pre-birth, and Target has your diaper business for a few years. So identifying pregnant individuals and getting their initial business is a huge boon.

Except people don’t like when you know something deeply personal about them — especially something they have not yet told their friends. Or found out about their kids — a man became quite irate when a “congrats, here are a bunch of coupons for baby things for you” flyer arrived for his daughter. His underage and certainly not pregnant daughter. The man expressed his anger to a manager at the local Target store. And had to ring the manager back later, after his daughter broke the news to her family. A company knew his daughter was pregnant before she braved telling her parents. I’m sure some adults found the flyers equally upsetting – how do they know?? I only told my husband and our parents … are they bugging our phones!?! Target ended up creating customized general flyers that happened to include a few coupons for baby stuff … along side chain saws, motor oil, and grills. Effective, but didn’t freak out potential customers.

My point being – companies don’t want to alienate potential customers. I search for a particular yarn online, and a few days later a flyer shows up for that yarn … I now have creepy negative feelings about the company sending the flyer.

Windows 10 Tablet Mode

Now I know the *right* answer is “don’t let your four year old randomly click stuff on your computer” … which is an extension of “don’t let your cat walk/sleep on your keyboard” (a maxim I could never convince my mom was a good rule for computer usage). But I booted my Windows 10 computer to find I no longer had a desktop. I’ve got some theme-colored background with a couple of icons. I can go to all apps. I can get into settings and all sorts of things.

Not a Windows desktop:

And I didn’t even know what this thing was called to Google how to get rid of it. A bunch of random clicking later, and I’ve discovered Windows 10 has a “tablet mode”. Which was turned on – and just like I could never figure out how a sleeping cat managed to hit the three-key command required to rotate an Intel graphics card display by 90º, I have no clue how Anya’s gotten into this particular mode. Luckily it’s easy to undo (click it to turn it off); voila, I’ve got a desktop again.

LAPS For Local Computer Administrator Passwords

Overview

LAPS is Microsoft’s solution to a long-existing problem within a corporation using Windows computers: when you image computers, all of the local administrator passwords are the same. Now some organizations implemented a process to routinely change that password, but someone who is able to compromise the local administrator password on one box basically owns all of the other imaged workstations until the next password change.

Because your computer’s local administrator password is the same as everyone else’s, IT support cannot just give you a local password to access your box when it is malfunctioning. This means remote employees with incorrect system settings end up driving into an office just to allow an IT person to log into the box.

With LAPS, there is no longer one ring to rule them all – LAPS allows us to maintain unique local administrator passwords on domain member computers. A user can be provided their local administrator password without allowing access to all of the other domain-member PCs (or a compromised password one one box lets the attacker own only that box). A compromised box is still a problem, but access to other boxes within the domain would only be possible by retrieving other credentials stored on the device.

Considerations

Security: The end user is prevented from accessing the password or interacting with the process. The computer account manages the password, not the user (per section 4 LAPS_TechnicalSpecification.docx from https://www.microsoft.com/en-us/download/details.aspx?id=46899).

Within the directory, read access is insufficient (per https://blogs.msdn.microsoft.com/laps/2015/06/01/laps-and-password-storage-in-clear-text-in-ad/) to view the attribute values. In my proposed deployment, users (even those who will be retrieving the password legitimately) will use a web interface, so a single service acct will have read access to the confidential ms-Mcs-AdmPwd attribute and write access to ms-Mcs-AdminPwdExpirationTime. There are already powershell scripts published to search an improperly secured directory and dump a list of computer names & local administrator passwords. You should run Find-AdmPwdExtendedrights -identity :<OU FQDN> to determine who has the ability to read the password values to avoid this really embarrassing oversight.

Should anyone have access to read the ms-Mcs-AdmPwd value beyond the service account? If the web interface goes down for some reason, is obtaining the local administrator password sufficiently important that, for example, help desk management should be able to see the password through the MS provided client? Depends on the use cases, but I’m guessing yes (if for no other reason than the top level AD admins will have access and will probably get rung up to find the password if the site goes down).

In the AD permissions, watch who has write permission to ms-Mcs-AdminPwdExpirationTime as write access allows someone to bump out the expiry date for the local admin password. Are we paranoid enough to run a filter for expiry > GPO interval? Or does setting “not not allow password expiration time longer than required by policy” to Enabled sufficently mitigate the issue? To me, it does … but the answer really depends on how confidential the data on these computers happens to be.

With read access to ms-Mcs-AdmPwdExpirationTime, you can ascertain which computers are using LAPS to manage the local administrator password (a future value is set in the attribute) and which are not (a null or past value). Is that a significant enough security risk to worry about mitigating? An attacker may try to limit their attacks to computers that do not use LAPS to manage the local admin password. They can also ascertain how long the current password will be valid.

How do you gain access to the box if the local admin password stored in AD does not work (for whatever reason)? I don’t think you’re worse off than you would be today – someone might give you the local desktop password, someone might make you drive into the office … but bears considering if we’ve created a scenario where someone might have a bigger problem than under the current setup.

Does this interact at all with workplace join computers? My guess is no, but haven’t found anything specific about how workplace joined computers interact with corporate GPOs.

Server Side

Potential AD load – depends on expiry interval. Not huge, but non-zero.

Schema extension needs to be loaded. Remove extended rights from attribute for everyone who has it. Add computer self rights. Add control access for web service acct – some individuals too as backup in case web server is down??

Does a report on almost expired passwords and notify someone have value?

Client Side

Someone else figures this out, not my deal-e-o. Set GPO for test machines, make sure value populates, test logon to machine with password from AD. Provide mechanism to force update of local admin password on specific machine (i.e. if I ring in and get the local admin password today, it should get changed to a new password in some short delta time).

Admin Interface

Web interface, provide computer name & get password. Log who made request & what computer name. If more than X requests made per user in a (delta time), send e-mail alert to admin user just in case it is suspicious activity. If more than Y requests made per user in a (longer delta time), send e-mail alert to admin user manager.

Additionally we need a function to clear the password expiry (force the machine to set a new password) to be used after local password is given to an end user.

User Interface

Can we map user to computer name and give the user a process to recover password without calling HD? Or have the manager log in & be able to pull local administrator for their directs? Or some other way to go about actually reducing call volume.

Future Considerations

Excluding ms-Mcs-AdmPwd  from repl to RODC – really no point to it being there.

Do we get this hooked up for acquired company domains too, or do they wait until they get in the WIN domain?

Does this facilitate new machine deployment to remote users? If you get a newly imaged machine & know its name, get the local admin password, log in, VPN in … can you do a run-as to get your creds cached? Or do a change user and still have the VPN session running so you can change to a domain user account?

LAPS For Servers: Should this be done on servers too? Web site could restrict who could view desktops v/s who could view servers … but it would save time/effort when someone leaves the group/company there too. Could even have non-TSG folks who would be able to get access to specific boxes – no idea if that’s something Michael would want, but same idea as the desktop side where now I wouldn’t give someone the password ‘cause it’s the password for thousands of other computers … may be people they wouldn’t want having local admin on any WIN box they maintain … but having local admin on the four boxes that run their app … maybe that’s a bonus. If it is deployed to servers, make sure they don’t put it on DCs (unless you want to use LAPS to manage the domain administrator password … which is an interesting consideration but has so many potential problems I don’t want to think about it right now especially since you’d have to find which DC updated the password most recently).

LAPS For VDI: Should this be done on VDI workstations? Even though it’s a easier to set the password on VDI the base VDI images than each individual workstation, it’s still manual effort & provides an attack vector for all of the *other* VDI sessions. Persistent sessions are OK without any thought because functionally no different than workstations. Non-persistent with new name each time are OK too – although I suspect you end up with a BUNCH of machine objects in AD that need to be cleaned up as new machine names come online. Maybe VDI sorts this … but the LAPS ‘stuff’ is functionally no different than bringing a whole bunch of new workstations online all the time.

Non-persistent sessions with same computer name … since the password update interval probably won’t have elapsed, the in-image password will be used. Can implement an on-boot script that clears AdmPwdExpirationTime to force change. Or a script to clear value on system shutdown (but that would need to handle non-clean shutdowns). That would require some testing.

 

Testing Process

We can have a full proof of concept type test by loading schema into test active directory (verify no adverse impact is seen) and having a workstation joined to the test domain. We could provide a quick web site where you input a computer name & get back a password (basically lacking the security-related controls where # of requests generate some action). This would allow testing of the password on the local machine. Would also allow testing of force-updating the local admin password.

Once we determine that this is worth the effort, web site would need to be flushed out (DB created for audit tracking). Schema and rights would need to be set up in AD. Then it’s pretty much on the desktop / GPO side. I’d recommend setting the GPO for a small number of test workstations first … but that’s what they do for pretty much any GPO change so not exactly ground breaking.

Self Driving Cars (or Market Driven Algorithms)

I don’t see much of a future for self-driving passenger vehicles. There are two non-tenable options for crash avoidance algorithms. Either the algorithm prioritizes my life and property (which means it would kill someone else to save my life … good for me, bad for society) or it won’t (great for society, but am I going to pay money for a car that will literally kill me to save someone else?). Does the computer assisted human driving model suffer this flaw? An algorithm that engages the brakes any time there is an obstacle within X feet fails to consider the vehicle that is about to slam into the side of your car if you don’t move it into the shrubbery ahead of you.

Self-driving unoccupied vehicles can simply de-prioritize itself (and the owner needs to accept that financial risk). We may see driving as a service (DaaS?) where a real human is responsible for making these split-second decisions. But allowing people to achieve the metro experience in their own vehicle (i.e. you sit and work for half an hour whilst your conveyance delivers you to your destination) is probably not going to happen.

Viewing Active Directory Object Metadata

Objects in active directory have a modification timestamp attribute, whenChanged, that reflects the time of the last change to the object. This is useful if you want to confirm a change had not been made after a specific time (e.g. the user began having problems at 2PM yesterday, but their object was last changed November of last year … an account change is not likely to be the cause).

There is additional stored metadata which provides a modification timestamp (and source domain controller for the modification event) for each individual attribute on an object. This can be a lot more useful (e.g. a user’s home directory is incorrect, but the object modification timestamp reflects the fact they changed their password yesterday). To view the metadata, use repadmin /showobjmeta DC-Hostname “objectFQDN”

I redirect the output to a file; it’s a lot easier to search a text file for the attribute name than scroll through all of the attributes in a DOS window.

repadmin /showobjmeta dc.domain.gTLD "cn=user account,ou=pathToObject,dc=domain,dc=gTLD" > myaccount.txt

57 entries.
Loc.USN Originating DSA                       Org.USN   Org.Time/Date       Ver   Attribute
======= ===============                       ========= =============       ===   =========
20822   92d3c1e5-d4ed-41c7-989f-62a1712b1084  20822     2014-06-08 22:20:57 1     cn
...
4659114 Default-First-Site-Name\DC            4659114   2016-12-29 20:56:21 10    unicodePwd
3299408 Default-First-Site-Name\DC            3299408   2016-01-16 17:03:05 13    lockoutTime
4978129 Default-First-Site-Name\DC            4978129   2017-02-18 21:50:13 90    lastLogonTimestamp
4988421 Default-First-Site-Name\DC            4988421   2017-02-22 10:31:06 54333 msDS-LastSuccessfulInteractiveLogonTime
4977488 Default-First-Site-Name\DC            4977488   2017-02-18 16:21:12 223   msDS-LastFailedInteractiveLogonTime
4977488 Default-First-Site-Name\DC            4977488   2017-02-18 16:21:12 223   msDS-FailedInteractiveLogonCount
4977489 Default-First-Site-Name\DC            4977489   2017-02-18 16:21:18 165   msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon

The originating DSA may be an odd GUID value (the domain controller on which this change was initiated has since been decommissioned) or it may be an AD site and domain controller name.

The originating timestamp indicates when the attribute’s value was last changed. The version indicates the number of revisions on the attribute value – which itself can provide interesting information like the number of times an account has been locked out or the number of times a user has changed their password.

This information can be useful when an account change does correspond with a user experiencing problems. You can identify the specific attributes that were updated and research those specific values.

It’s also useful to track down who changed a specific attribute value. The combination of originating domain controller and attribute modification time can make searching for the event log record corresponding to a specific change a lot easier — you know which server to search and can filter the log down to records spanning a few seconds.

 

Serial Port Sniffer

We use a Wink hub to communicate with our ZigBee devices – scripts on the OpenHAB server make web calls over to the Wink hub to set bulb levels. Works great on outbound communication to the bulbs, but it is not real-time bi-directional (i.e. if a bulb level is changed elsewhere, OpenHAB would need to poll and get the new value). Doesn’t matter for the GE Link bulbs because there isn’t another way they get set beyond dropping and returning power (which turns the bulb on at 100%), but we cannot use the Wink hub to communicate with interactive devices — unlock the door manually and OpenHAB has no idea the light should be turned on until the next polling cycle. And polling is a lot of extra overhead – check every device every minute 24×7. And it’s slow – hit the polling cycle wrong and it takes a minute from unlocking the garage door before the light turns on.

Had the idea of monitoring data that moves across the serial interfaces and use a script to communicate real-time inbound changes over to OpenHAB. Watching the serial interface, we get lots of cryptic traffic from socat:

socat -x /dev/SerialPort,raw,echo=0,crnl PTY,link=/dev/ttyV1,raw,echo=0,crnl

Amazon Prime Household and Security (or lack thereof)

There are a lot of odd security lapses in Amazon’s implementation of Prime Household. Anything that uses Alexa creates shared cards that are visible in the Alexa app. There’s some implicit trust between family members, but even married people may not want to share EVERYTHING. “Echo, add this present for my wife to the list” shows up as a card in your wife’s Alexa app.

We share an Amazon Prime Household with Scott’s dad. We both have Alexa-enabled devices (FireTVs and Dots). Our Dots interact with our home automation system through a Phillips bridge emulator. Scott’s dad has some smart devices, but his FireTV could not find any smart devices when it would search. It would, however, turn the ‘outside lights’ on and off. Except the lights didn’t turn on or off in his house.

Our outside lights started turning on and off one night. We have a lot of home automation, but nothing in the logs indicated why this was occurring. I’m not sure if Scott called him or he called Scott, but we were lucky not to spend a day trying to track down some crazy issue. Evidently your Alexa can switch between profiles on the Amazon Prime Household just by saying “switch accounts”. You can ask it “which account is this?”.

The thing I find odd — our HA Bridge is not publicly addressable. Evidently any device on your account can have another device on your account initiate communication. Otherwise there’s no way a device that is connected to our profile but NOT on our network would be able to communicate with the HA Bridge.

Web-Accessible History From OpenHAB MySQL Persistence Database

My husband has wanted a quick/easy way to see the data stored in OpenHAB’s MySQL persistence database, so I put together a very quick (and ugly) PHP page that provides a list of all Items. If you click on an item, you can page through the item’s records. The index.php from the page is available here. You need a web server (I am using Apache on Fedora), PHP (I am using 5.6) and MySQLi (php-mysqlnd package).

This is a bit of paranoia on my part, but even on a page that is ONLY available internally … I don’t like to use an account with read/write access to display data. I create a new user and assign read access:

CREATE USER 'YourUserName'@'localhost' IDENTIFIED BY 'P#ssw0rdH3r3';
GRANT SELECT ON openhabdb.* to 'YourUserName'@'localhost';
FLUSH PRIVILEGES;

Then use *that* user in the php code. This example has a web server running on the database server – and you connect to the MySQL server via localhost. If your web server is located on a different host, you’ll need to create and grant ‘YourUserName’@ the web server hostname.

Custom Password Filter Update (unable to log on after changing password with custom filter in place)

I had written and tested a custom Active Directory password filter – my test included verifying the password actually worked. The automated testing was to select a UID from a pool, select a test category (good password, re-used password, password from dictionary, password that doesn’t meet character requirements, password containing surname, password containing givenName), set the password on the user id. Record the result from the password set, then attempt to use that password and record the result from the bind attempt. Each test category has an expected result, and any operation where the password set or bind didn’t match the expected results were highlighted. I also included a high precision timer to record the time to complete the password set operation (wanted to verify we weren’t adversely impacting the user experience). Published results, documented the installation and configuration of my password filter, and was done.

Until the chap who was installing it in production rang me to say he couldn’t actually log in using the password he set on the account. Which was odd – I set one and then did an LDAP bind and verified the password. But he couldn’t use the same password to log into a workstation in the test domain. Huh?? I actually knew people who wanted *some* users to be able to log in anywhere and others to be restricted to LDAP-only logons (i.e. web portal stuff) and ended up using the userWorkstations attribute to allow logon to DCs only.

We opened a case with Microsoft and it turns out that their Password Filter Programming Considerations didn’t actually mean “Erase all memory used to store passwords by calling the SecureZeroMemory function before freeing memory.” What they meant was “If you have created copies of the password anywhere within your code, make sure you erase memory used to store those copies by calling SecureZeroMemory …”

Which makes SO much more sense … as the comments in the code I used as our base says, why wouldn’t MS handle wiping the memory? Does it not get cleaned well if you don’t have a custom password filter?? Remarked out the call to SecureZeroMemory and you could use the password on NTLM authentications as well as kerberos!

// MS documentation suggests doing this. I honestly don’t know why LSA
// doesn’t just do this for you after we return. But, I’ll do what the
// docs say…
// LJR – 2016-12-15 Per MS, they actually mean to wipe any COPIES you make
// SecureZeroMemory(Password->Buffer, Password->Length);

 

I’ve updated my version of the filter and opened an issue on the source GitHub project … but if anyone else is working a custom password filter, following MS’s published programming considerations, and finds themselves unable to use the password they set … see if you are zapping your copies of the password or the PUNICODE_STRING that comes in.