ShabbyDoo
Joined 18 years ago
Joined 18 years ago
1. Was this GIF-fetching endpoint likely exposed publicly by most customers' SolarWinds deployments?
2. Public or not, was there any auth in front of this endpoint when deployed?
My presumption is that some (most?) customers deployed the SolarWinds admin console publicly (with its own auth in front) and that this particular GIF-fetcher endpoint, being deemed trivial, was not protected by the console's auth scheme. Thus, those who knew about the trojan just had to scan the known IP ranges of SolarWinds customers until they found the exposed admin console, and then remote code execution was easy from there.
If this endpoint was protected by the same auth scheme as the admin console, then this trojan becomes more of a privilege escalation attack. Its existence would increase the value of obtaining the creds of a SolrWinds user, but (presuming SSO integration) those creds would get the attackers lots of other access given the sorts of IT people who use SolarWinds.
If the endpoint was not fronted by any auth scheme but the admin console was not exposed externally, then the benefit would be that attackers who gained access to a SolarWinds customer's employee-facing network (what's the name for the network segments accessible to anyone who plugs in a laptop in a cubicle?) could "ride" this trojan to gain access to a more privileged part of the network.
I'm not an infosec guy. Do these arguments make sense?
I own a Fujitsu Scansnap s1500. It's out of support, and the existing drivers are incompatible with Catalina. I now must pay a 3rd party $100 for drivers or fiddle around with a Linux scanner server or similar. Never again will I pay $400 for a Fujitsu scanner, that's for sure.
http://openjdk.java.net/projects/code-tools/jmh/
It takes care of details like JVM warm-ups. ensuring sufficient invocations for JIT compilation to have occurred, etc.
I like how the author says that sprawl isn't the problem, the problem is that new developments are large scale, single-purpose, and with no room for improvement or addition.
The graph/map showing how downtown and poorer areas bring in more tax is what did it though. Even just thinking about ploughing in the winter makes it pretty clear that winding suburbian roadscapes are costing the city a lot more than we pay them. That's without mentioning schools, fire halls, garbage collection, etc.
I guess one of the more difficult issues is convincing North Americans that they don't need a private single-family house, large yard, 2+ cars, etc.
The article doesn't mention one seemingly huge benefit of JIT compilation: profile-guided optimization:
http://www.slideshare.net/ZeroTurnaround/vladimir-ivanovjvmj...
Perhaps the baby has been thrown out with the bathwater?
Little is mentioned about how ART compares to the JVM. For example, does ART perform escape analysis? Not all object allocations are equally bad. The Sun JVM can figure out which objects may be allocated on TLABs (Thread Local Allocation Buffers) - an optimization which reduces the burden placed on the garbage collector because TLAB-resident objects may be deallocated as the stack is popped. [Please fact-check me as I'm merely a long-time Java developer vs. an expert on JVM internals]
I suppose the relevance of my entire comment hinges on the presumption that anyone reading HN only uses hotel PCs for printing stuff. Valid?
So, what's left? Collusion between buyer and space provider -- in all likelihood, they are one in the same, or identities have been stolen. For example, I list my condo on AirBnB for $100/night. Someone books it for the weekend, and then doesn't show up. AirBnB owes me $200 -- after all, I gave up other options to profit from its use. An honest buyer pays up. But, maybe the buyer is dishonest -- he used a stolen credit card, etc. In this case, AirBnB eats the loss and pays me as the space provider. Now, wouldn't it be convenient if I was also the buyer? Cash from stolen credit cards, funneled through AirBnB (much akin to the way online poker sites were used to transfer stolen money via bad heads-up play). This would work until AirBnB noticed that my listing seems to have a suspicious propensity to attract fraudulent buyers. Then, they'll shut me down. So, I'll pop-up elsewhere. After all, no need to actually have a space because no one I accept will ever show up!
I bet the usage patterns of the party/parties involved in this fraud are drastically different than those of legitimate market participants. Someone with a fraudulent listing could out himself by rejecting a bunch of legitimate AirBnB buyers, and this behavior would stand-out as it's the opposite of the behavior expected of an honest seller. So, he must protect against this risk by making his listing unappealing (high price, bad photos/description, unpopular location, etc.). The behavior of users browsing AirBnB when viewing this property could identify its relative undesirability (few clicks, etc.), and price outliers could be identified by comparing similar offerings by date/location/type. The click stream of the "buyer" likely is most revealing. Someone selecting an unappealing property without doing much comparison shopping likely isn't a legit buyer.
What other stuff might predict fraud? Vague descriptions might indicate a fraudulent listing. Most space providers love to tell buyers what's special about their offering. Could some scoring of a listing's prose prove a strong predictor? I've never listed with AirBnB. What do they do to verify listings? As a buyer, they verified my identity. Could this serve multiple purposes? Certainly, I'd feel better listing my guest room if I know that AirBnB will know the identity of the guy who rented the room and then stabbed me at 3AM. But, in addition, does identifying market participants in strong ways help keep fraudsters from repeating their crimes by setting up multiple accounts? Obviously, newer market participants are more risky than established ones, especially those who have interacted with known legit, long-time users. The social graph comes to the rescue here. Even astroturfing ought to show up as a small, disconnected graph unless legit users' identities are stolen.
Of course, this comment is all just conjecture. Obviously, AirBnB can't tell the public about specific fraud methods or how they identify suspicious activity. However, I like the concreteness of considering actual fraud scenarios, so I decided to put forth some ideas for discussion.
My understanding of container shipping is that customers make SLA choices much akin to us Americans choosing between UPS Ground/2nd Day Air/Next Day, etc. UPS uses these varied SLAs to smooth out its use of fleet capacity and for price discrimination. Shippers operate transshipment ports as part of distribution networks much like the hub & spoke designs of the major airlines. These ports have a bunch of shipping containers sitting around awaiting capacity.
Consider the needs of companies that must transport low-value, high weight/bulk cargo. These companies likely already choose the "UPS Ground" equivalent for container shipping. Due to low product value, inventory costs are low (in transit goods are inventory), so it's probably less expensive to have buffers of goods in the supply chain than it is to pay for tight shipping SLAs. Why should these companies care if the variance they experience in shipping duration is due to capacity constraints of manned-ships or that it took an extra two weeks to fix the ship upon which their cargo was in transit?